[tptacek]

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?

[tenken]

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.

[tptacek]

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.

[tenken]

Thanks!

[4kevinking]

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.

[tptacek]

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.

[4kevinking]

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