OpenSSH 5.4 was released on 2010-03-08, and that is when the project added support for certificate authentication of users and hosts using an OpenSSH certificate format (not X.509)

Why am I telling you this? Because I wanted to find out since when exactly I have been putting off actually experimenting with SSH certificates, and I can now with certainty say that as far as this topic is concerned I've been an idiot over the last 16 years!

sshd-session[4063]: error: Certificate invalid: expired

Really good!

sshd-session[4077]: error: Certificate invalid: name is not a listed principal

and if need be (I'm just verifying it actually works) we can sign SSH certificates with #Ansible
@jpmens great but.... I kinda feel like why invent yet another new cert format when you could've just used attribute extensions in X.509?

@hyc simplicity, ease of use, easy to handle and copy/paste?

here's a certificate

@jpmens tell us more? In which way is it better?

@cynicalsecurity oof, you're asking a beginner ...

No more TOFU (servers are implicitly trusted), principal names in cert define as *which* users I can login. Validity times (also relative) can be specified (cynicalsecurity can login for 2 days), remote commands can be enforced, and lots more probably.

@cynicalsecurity most importantly: no more authorized_keys files, no known_hosts updating on client (ie. servers can change host key without *** WARNING)

@jpmens @cynicalsecurity I thought known_hosts still updated, just quietly / no prompt because of trusted root cert.

Am I wrong?

@cynicalsecurity @jpmens My former company still uses SSH certs. From top of my head:

- auditable root access without su/sudo
- expiration (no left over access)
- user restrictions bound to certs (instead of server config)

+ human user priv keys were HW bound

https://github.com/silentsignal/zsca
GitHub - silentsignal/zsca: Zero-trust SSH CA

Zero-trust SSH CA. Contribute to silentsignal/zsca development by creating an account on GitHub.

GitHub
@buherator OK, this is *nice*… another one who has not been reading the manual since 2010 joins the club … @jpmens
Scalable and secure access with SSH

Visit the post for more.

Engineering at Meta

@buherator exactly that post is what got me interested at the time (before I put it all aside for many years :-( )

@cynicalsecurity

@buherator @cynicalsecurity @jpmens I built a solution based on that feature with a YubiHSM to generate short term certificates for security agents to log into machines, do their job, and get out, without worrying about permanent accounts or certificate management. Worked great 🙂
@JP Mens Same here. I was immediately interested when I first read about it, but haven't actually experimented with it either....

Putting it back on the to do list.
@hans c'est presque magique :-)
@jpmens in the same boat, but since ssh keys do what I need, I may remain in this boat for a while.
@jpmens I find this a good enlightening past experiment with all sorts of nice properties: https://speakerdeck.com/rlewis/how-netflix-gives-all-its-engineers-ssh-access-to-instances-running-in-production (ephemeral certificates with a static CA) and hence https://github.com/Netflix/bless
How Netflix Gives All Its Engineers SSH Access To Instances Running In Production

One of the ways Netflix enables engineering velocity is with the Freedom and Responsibility culture that empowers individuals with the freedom to do wha…

Speaker Deck
@pmevzek thank you, I enjoy reading how/what others have done!

@pmevzek good ideas in that slide deck, and thank you -- interesting.

Pity that the BLESS software (meanwhile put to pasture by Netflix) requires AWS. I've also been looking at step (https://smallstep.com/blog/use-ssh-certificates/) which seems well documented etc, but they seem to need an IDP which is probably fine for very large orgs but surely overkill for smallish projects.

If you’re not using SSH certificates you’re doing SSH wrong

SSH has some pretty gnarly issues when it comes to usability, operability, and security. The good news is this is all easy to fix. SSH is ubiquitous. It’s the de-facto solution for remote administration of *nix systems. SSH certificate authentication makes SSH easier to use, easier to operate, and more secure.

@jpmens I've been doing this for a while and it's been great https://jamesog.net/2023/03/03/yubikey-as-an-ssh-certificate-authority/
YubiKey as an SSH Certificate Authority

This is a guide to setting up a YubiKey for use as an offline SSH certificate authority. This assumes a brand new YubiKey with no prior configuration on it, to be used solely as a CA. Why? Typically a CA should be on a secured, isolated machine. Using a dedicated YubiKey means you can isolate your CA and keep it in a drawer so that it can’t be accessed. YubiKeys offer protections such as requiring a PIN and/or touching the key for PIV operations.

@jamesog very good writeup and thank you.

I see you've added stuff to ensure I had a coffee before starting!

I stumbled over "first" and "second" the as order is swapped. (Just a small nit.)

@jamesog I think there might be a copy/paste error here, or is it actually the Yubikey which is inaccurately reporting the slot number?

Checking my own 5C NFC (version 5.4.3) I note slot numbers are strangely reported... [strange meaning "I don't understand"]

Slot 8A (RETIRED9):

@jpmens That’s my mistake I think. I had tried with several Yubikeys to test the process and I vaguely recall being unsure which slot to use (or if it even mattered). I’ll check that later too. Thanks!
@jpmens Ooh thanks. I’ll check that later. It was stitched together from a lot of different notes and terminal scrollback!
@jamesog I know what that's like :-) and I wasn't complaining just pointing out discrepancies I noticed (hoping they actually are such so as not to embarrass myself :-)
@jpmens I appreciate the feedback :-)