Hacker News new | ask | show | jobs
by EthanHeilman 453 days ago
The benefits of this is that you don't have the attack surface of an SSH CA. If you do this with an SSH CA that supports OIDC, if either the IDP or the SSH CA are compromised then security is lost.

With OpenPubkey and by extension opkssh, your IDP is functioning like the SSH CA by signing the public key that you make the SSH connection with. Thus, you have one fewer trusted party and you don't have maintain and secure an SSH CA.

Beyond this, rotating SSH CAs is hard because you need to put the public key of the SSH CA on each SSH server and SSH certs don't support intermediate certificates. Thus if you SSH CA is hacked, you need to update the CA public key on all your servers and hope you don't miss any. OpenID Connect IDPs rotate their public keys often and if they get hacked and they can immediately rotate their public keys without any update to relying servers.

1 comments

You can have multiple trusted CAs which I've found to make rotation a non issue with tooling like Ansible etc.

New CA is minted, public key is added to the accepted list, client signing start using the new CA and you remove the old after a short while.

If missing servers is a common problem it sounds like there are some other fundamental problems outside just authenticated user sessions.

That's smart! You could probably automate that using a cron job pulling the latest CA public keys so servers automatically rotates CA public keys every few days.

> If missing servers is a common problem it sounds like there are some other fundamental problems outside just authenticated user sessions.

On one hand yes, on the other hand that is just the current reality in large enterprises. Consider this quote from Tatu Ylonen's (Inventor of SSH) recent paper [0]

“In many organizations – even very security-conscious organizations – there are many times more obsolete authorized keys than they have employees. Worse, authorized keys generally grant command-line shell access, which in itself is often considered privileged. We have found that in many organizations about 10% of the authorized keys grant root or administrator access. SSH keys never expire.”

If authorized keys get missed, servers are going to get missed.

opkssh was partially inspired by the challenges presented in this paper.

[0]: Challenges in Managing SSH Keys – and a Call for Solutions https://ylonen.org/papers/ssh-key-challenges.pdf