Hey HN, we’re happy to announce that Krypton for Teams is now available! Thanks for all your support when we debuted Krypton Core, your early feedback strongly influenced the Teams product.
Krypton for Teams builds on Core to make DevOps key management easy and secure by default. We designed Teams to be cryptographically end-to-end verified using signed hash chains. Even if our infrastructure is attacked your team data cannot be altered.
How does this work with modern SSH access management? If you were talking to an organization about maybe adopting this, and they told you they were planning in the medium term to move to a system where developers 2FA-authed to an auth server and got issued time-limited SSH certificates, where would your thing fit in?
Pardon my ignorance, what is "modern ssh access management" ... Is there a toggle on an OS to enforce this lease-mode mode ssh, like say on Ubuntu 18.04 LTS.
... Or are you speaking about some niche ssh key usage paradigm such as a apart of a custom keyring authorization access system for short term client usage to a service.
The SSH key stored in Krypton can be signed just like a local key-pair. The public key is stored in ~/.ssh/id_krypton.pub and SSH will look for the cert at ~/.ssh/id_krypton-cert.pub.
1. All team actions should be prefixed under "kr team", right now i don't know what happens if i run "kr add" if i only want to add myself to a server, ie outside my team.
2. What user's 'authorized_keys' would "kr add" write with a team? I don't want a team to share a single user.... luxury problem, but hey.
3. Make it possible to try local keys before krypton
Point taken, the intention is to make each command more succinct and we overloaded the functionality of `kr add` to do so.
`kr add` will add your public key if no members are specified. The user being modified is whichever is being logged into. So if you have an ssh alias "bastion" that specifies user "jump" in your SSH config, `kr add bastion` adds your public key to user "jump". Just like when SSHing into a server, you can override the default user in the form `kr add user@bastion`.
This is only the first iteration of `kr add`, and we will be adding more advanced access control in the near future, including authenticating as one user but modifying another.
Totally agree with 3., we'll add this to our roadmap.
Cool. I started building out something similar-ish once, but used a slack bot instead of mobile. I wasn't as concerned with temporary SSH creds, as much as I just wanted a way to on-demand punch holes in security groups to give limited access to a bastion host in a auditable way (and have them closed automatically when I was done). Definitely good to see more innovation happening in this space.
So I really wanted to use this for our team but hit a few problems. This seems to run on AWS and so does most of our systems if this does not work and with no way to export the private keys I assume there is no way to SSH. Also it seems to use the same key for team stuff as personal stuff showing personal git commits in the audit log.
Krypton supports bluetooth for so even if SQS and SNS are down -- you can still SSH. We'll also shortly be rolling out USB support just incase bluetooth also happens to not be working :)
There isn't a good division between personal and work use yet -- this is something that's coming (i.e. multiple teams/keys support).
So I have a Linux laptop with full disk encryption that only gets used for work stuff and lives in the office 5-6 out of 7 days. If I move it, I'm paying attention.
Contrast to my personal Android phone I carry everywhere - so how is that more secure for an SSH key to live on?
Persuade me or at least tell me where I misread the webpage :)
A while ago I made https://www.sshpubkey.com/ to store different ssh public keys across different hosts. But Krypton appears to be a much more intelligent way of approaching the problem, especially for teams.
Yes! This is coming in the next few months. You'll be able to require multiple admins to approve production releases or really lock up sensitive machines. Supervised access (requesting short-lived access to a server in real-time) is coming too!
[+] [-] agrinman|8 years ago|reply
Krypton for Teams builds on Core to make DevOps key management easy and secure by default. We designed Teams to be cryptographically end-to-end verified using signed hash chains. Even if our infrastructure is attacked your team data cannot be altered.
Looking forward to your feedback!
[+] [-] tptacek|8 years ago|reply
[+] [-] tenken|8 years ago|reply
... Or are you speaking about some niche ssh key usage paradigm such as a apart of a custom keyring authorization access system for short term client usage to a service.
thanks.
[+] [-] 4kevinking|8 years ago|reply
[+] [-] apazgo|8 years ago|reply
2. What user's 'authorized_keys' would "kr add" write with a team? I don't want a team to share a single user.... luxury problem, but hey.
3. Make it possible to try local keys before krypton
4. Great work!
[+] [-] 4kevinking|8 years ago|reply
`kr add` will add your public key if no members are specified. The user being modified is whichever is being logged into. So if you have an ssh alias "bastion" that specifies user "jump" in your SSH config, `kr add bastion` adds your public key to user "jump". Just like when SSHing into a server, you can override the default user in the form `kr add user@bastion`.
This is only the first iteration of `kr add`, and we will be adding more advanced access control in the near future, including authenticating as one user but modifying another.
Totally agree with 3., we'll add this to our roadmap.
Thanks!
[+] [-] sudosteph|8 years ago|reply
[+] [-] MightySCollins|8 years ago|reply
[+] [-] agrinman|8 years ago|reply
There isn't a good division between personal and work use yet -- this is something that's coming (i.e. multiple teams/keys support).
[+] [-] wink|8 years ago|reply
Contrast to my personal Android phone I carry everywhere - so how is that more secure for an SSH key to live on?
Persuade me or at least tell me where I misread the webpage :)
[+] [-] aaomidi|8 years ago|reply
It's kinda like yubikey vs having a PGP key.
[+] [-] hkhanna|8 years ago|reply
A while ago I made https://www.sshpubkey.com/ to store different ssh public keys across different hosts. But Krypton appears to be a much more intelligent way of approaching the problem, especially for teams.
Great work.
[+] [-] muzakthings|8 years ago|reply
Do you have planned support for consensus-type mutlisig access? (ie: needing M of N approvals to acccess resources)
[+] [-] agrinman|8 years ago|reply