Show HN: Krypton for Teams – Simple SSH Key Storage for DevOps
1–10 of 20 posts
Re: Show HN: Krypton for Teams – Simple SSH Key Storage for DevOps
#2Hey 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.
Looking forward to your feedback!
Re: Show HN: Krypton for Teams – Simple SSH Key Storage for DevOps
#3This is super cool!
Do you have planned support for consensus-type mutlisig access? (ie: needing M of N approvals to acccess resources)
Re: Show HN: Krypton for Teams – Simple SSH Key Storage for DevOps
#4This is super cool! Do you have planned support for consensus-type mutlisig access? (ie: needing M of N approvals to acccess resources)
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!
Re: Show HN: Krypton for Teams – Simple SSH Key Storage for DevOps
#5How 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?
Re: Show HN: Krypton for Teams – Simple SSH Key Storage for DevOps
#6How 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?
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.
Re: Show HN: Krypton for Teams – Simple SSH Key Storage for DevOps
#7How 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?
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.
Right, but that's a long-lived durable SSH credential. Part of the point of modern SSH access management is not to have any of those anymore.
Re: Show HN: Krypton for Teams – Simple SSH Key Storage for DevOps
#8Krypton looks awesome!
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.
Re: Show HN: Krypton for Teams – Simple SSH Key Storage for DevOps
#9Cool. 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.
Re: Show HN: Krypton for Teams – Simple SSH Key Storage for DevOps
#10Earlier quoted context omitted.
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.
Right, but that's a long-lived durable SSH credential. Part of the point of modern SSH access management is not to have any of those anymore.
Yes in this case the Krypton SSH key pair is long-lived, but the certificate issued to it by the server would be short-lived.
How are users authenticating to this 2FA CA in the first place? Instead of using username/password and 2FA, users could authenticate to the CA using Krypton and then use the issued certificate for short-lived access.
If Krypton using a long-lived SSH keypair is a non-starter, automatic key rotation could be added down the line (sort of like being forced to change your password but this would be automated).