Show HN: Krypton for Teams – Simple SSH Key Storage for DevOps | Hacker News Reader

Show HN: Krypton for Teams – Simple SSH Key Storage for DevOps

krypt.co

53 points4kevinking19 comments

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.

Looking forward to your feedback!

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?

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).

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.

thanks.

The Google search you want to do is "SSH certificate authority". There's no one thing; it's just a trend in high-end SSH management.

Thanks!

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

4. Great work!

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.

Thanks!

Problem with `kr add user@bastion` is that you as `user1` won't normally have access to ssh as `user2`, but "authenticating as one user but modifying another" would work of course. Maybe add a option for team-members to save their username for servers, then mass-add would be easy :)

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 :)

Most android phones have hardware backed secure storage. You can't read the raw files once they're there.

It's kinda like yubikey vs having a PGP key.

Krypton 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.

This 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!

Reply on news.ycombinator.com