This is great, and helps solve several problems at once.
I would like to remind everyone that an internet facing SSH with a password is very unwise. I would argue you need to be able to articulate the justification for it, using keys is actually more convenient and significantly more secure.
Aside from initial boot, I cannot think of the last time I used a password for SSH instead of a key even on a LAN. Support for keys is universal and has been for most of my lifespan.
There's a high bar to set for most organizations. Leveraging certificates is excellent if the supporting and engineering actors are all in accordance with how to manage and train the users and workforce how to use them (think root authorities, and revoking issued certificates from an authority).
I've seen a few attempts to leverage certificates, or GPG; and keys nearly always are an 'easier' process with less burden to teach (which smart(er) people at times hate to do).
You can store your regular keys in gpg, it's a nice middle ground especially if you store them on a yubikey with openpgp.
Of course OpenSSH also supports fido2 now but it's pretty new and many embedded servers don't support it. So I'm ignoring it for now. I need an openpgp setup for my password manager anyway.
I use both PKCS#11 and OpenPGP SSH keys and in my opinion, PKCS#11 is a better user experience if you don't also require PGP functionality. Especially if you're supporting MaxOS clients as you can just use Secretive[0]. As you say, FIDO is even better but comes with limitations on both client and server, which makes life tough.
Oh yeah I don't really use macOS anymore. And I do really need PGP functionality for my password manager.
I used pkcs11 before with openct and opensc (on OpenHSM PIV cards) and the problem I had with it was that I always needed to runtime-link a library to the SSH binary to make it work which was often causing problems on different platforms.
The nice thing about using PGP/GPG is that it can simulate an SSH agent so none of this is necessary, it will just communicate with the agent over a local socket.
By the way, to elaborate, I love it because it's really secure when used with yubikeys, it's fully self hosted, it works on all the platforms I use including android and it's very flexible. There's no master password to guess which is always a bit of an Achilles heel with traditional PW managers. Because you have to use it so much you don't really want to have it too long or complex. This solves that while keeping it very secure.
The one thing I miss a bit is that it doesn't do passkeys. But well.
I use it as well (with a Yubikey) and I love it! On Android I use Android-Password-Store [1], which is nice too. There is just this issue with OpenKeychain that concerns me a bit, I am not sure if Android-Password-Store will still support hardware keys when moving to v2... but other than that it's great!
SSH Certificates are vastly different then the certificates you are referencing.
SSH Certificates are actually just a SSH Key attested by another SSH Key. There's no revocation system in place, nor anything more advanced then "I trust key x and so any keys signed by X I will trust"
There is a revocation system in place (the RevokedKeys directive in the sshd configuration file, which seems to be system-wide rather than configured at the user-level. At least, that’s the only way I’ve used it)
I agree with the sentiment though, it is far less extensive than traditional X.509 certificate infrastructure.
when I said revocation system, I intended to convey something similar to Online Certificate Status Protocol, rather then a hardcoded list that needs to be synchronized between all the physical servers.
You are correct though, you can keep a list and deploy it to all the nodes for revocation purposes.
It's unfortunate that there's no RevokedKeysCommand to support building something like OCSP.
I am no familiar with SSH certificates either. But if there is no revocation system in place, how can I be sure access from a person can be revoked?
At our org we simply distribute SSH public keys via Puppet. So if some leaves, switches teams (without access to our servers) or their key must be renewed, we simply update a line in a config file and call it a day.
That way we also have full control over what types of keys are supported and older, broken kex and signature algorithms are disabled.
The certificates have a validity window that sshd also checks. So the CA can sign a certificate for a short window (hours), until the user has to request a new one.
One department in my cops y does this - you authenticate once with your standard company wide oidc integration (which has instant JML), and you get a key for 20 hours (enough for even the longest shift but not enough that you don’t need to reauth the next day).
I like SSH certificates, and I use them on my own servers, but for organizations there's a nasty downside: SSH certificates lack good revocation logic. OCSP/CRL checks and certificate transparency protect browsers from this, but SSH doesn't have that good a solution for that.
Unless you regenerate them every day or have some kind of elaborate synchronisation process set up on the server side, a malicious ex-employee could abuse the old credentials post-termination.
This could be worked around leveraging TPMs, which would allow storing the keys themselves on hardware that can be confiscated, but standard user-based auth has a lot more (user-friendly) tooling and integration options.
It seems to me like short-lived certificates are the way to go, which would require tooling. I am actually a little surprised to hear that you're using long-lived certificates on your own servers (I'm imagining a homelab setup). What benefit does that provide you over distributing keys? Who's the CA?
I'm my own CA; SSH certificates don't usually use X509 certificate chains. I dump a public key and a config file in /etc/ssh/sshd_config.d/ to trust the CA, which I find easier to automate than installing a list of keys in /home/user/.ssh/authorized_keys.
I started using this when I got a new laptop and kept running into VMs and containers that I couldn't log into (I have password auth disabled). Same for some quick SSH sessions from my phone. Now, every time I need to log in from a new key/profile/device, I enroll one certificate (which is really just an id_ecdsa-cert.pub file next to id_ecdsa.pub) and instantly get access to all of my servers.
I also have a small VM with a long-lasting certificate that's configured to require username+password+TOTP, in case I ever lose access to all of my key files for some reason.
Some would argue that in an organization where you'd consider SSH certificates, it's best to use Kerberos and have general SSO. (Some of the GSSAPI functionality is patched in by most distributions, and isn't in vanilla OpenSSH.)
I resent that every application needs its own special snowflake auth method. One uses a certain 2fa app. Another uses another 2fa app. Another uses emailed code. Another uses text code. Another uses special ssh keys. Another opens a prompt in the browser where I have to confirm. Another uses special scoped tokens.
Yes there are good reasons. But it is quite a hassle to manage too.
Nope, still unwise. Easy to steal, easy to clone, hard to script. Keys stored in hardware is simple and easy on most platforms these days. Yubikeys or Mac SEP is ideal.
Technically it's easier to steal a private key off of disk than it is to steal a password from inside a person's head or to plant a keylogger. If a keylogger is in place, someone can likely already also access your disk and the password used to protect the private key (or your password manager).
It depends on your use case. I have a personal server only I use use. In this use case, being able to access it from anywhere without any device trumps other considerations. The password is ideal.
In a corporate setting, things are of course different.
My use case is the same as yours. Malware can steal your credentials, it cannot steal mine. I also don't need fail2ban or to configure any of these new OpenSSH features. Users added to the server can't get compromised due to use of weak passwords.
Passwords are obsolete in 2024, and using them is very nearly universally bad.
> Passwords are obsolete in 2024, and using them is very nearly universally bad.
The first claim is obviously nowhere near being true, and the second seems very subjective.
As the other user is saying, strong passwords with proper security have minimal risk. More than certs or keys yes, but they offer sufficient security and the balance with convenience is currently unbeatable.
Besides, even if someone gets access to your server they should be limited and unable to do any real damage anyway. Defense in depth and all that.
> I also don't need fail2ban or to configure any of these new OpenSSH features
Me neither. If your password has sufficient entropy, you don't need any of this.
> Malware can steal your credentials, it cannot steal mine
The only solution around this is a hardware key or MFA. I find the convenience of not needing anything with me to be superior to the low risk of malware. I understand your opinion may differ here.
> I would like to remind everyone that an internet facing SSH with a password is very unwise.
Bullshit. You can have a terrible password and your system will still be nearly impossible to get into. Also, these attackers are usually looking for already exploited systems that have backdoor account/password combos, unless they are specifically attacking your organization.
Repeat after me: dictionary attack concerns have nothing to do with remote access authentication concerns.
Let's say my password is two common-use English words (100k-200k.) That's ten billion possibilities. Assume you hit on my password half-way through. That would be fifteen years of continuous, 24x7x365 testing at 10 password attempts per second....and then there's the small matter of you not knowing what my username is, or even whether you've got the right username or not, unless the ssh server has a timing-based detection attack.
The only argument for putting this functionality in the daemon itself is that by locating it in the daemon, it can offer advanced application-layer capabilities, such as failing auth attempts no matter what after the limit is tripped so that brute-forcing becomes more pointless - unless you get it right within the first few attempts, you could hit the right password and never know it. If they intend to implement features like that in the future, great - but if it's just going to do what fail2ban does, then...just run fail2ban.
Fail2ban has a higher overview of auth on the system, is completely disconnected from the ssh daemon in terms of monitoring and blocking, and the blocking it does happens at the kernel level in the networking stack instead of in userspace with much more overhead and in a proprietary system specific to SSH.
As a sysadmin, this is 'yet another place you have to look' to see why something isn't working.
> You can have a terrible password and your system will still be nearly impossible to get into.
Ok, let's try an example of a terrible password for the user "root": "password". Is that nearly impossible to get into? Or does that not qualify as a "terrible password" per your definition?
The two aren't exclusive of one another. We've also witnessed situations, with major companies, wherein an SSH "leaks" outside the VPN due to network misconfiguration or misconfiguring interfaces on the server.
As I said above, keys are actually more convenient than passwords. Only reason people still use passwords is because they believe keys are difficult to use or manage.
This, with key pairs, is the best blend of security and convenience. I use ZeroTier and UFW on the server and it’s really very simple and extremely reliable. On the very rare occasion that ZeroTier encounters a problem, or my login fails, I still have IPMI access through Proxmox/VMWare and/or my server provider.
IDD, but it depends on your threat model. Personally, it's a tradeoff I'm happy to make, but an alternative would be setting up your own VPN, e.g. Wireguard.
If I can be charitable, I think they mean a different computer than one you usually use (that doesn’t have the SSH key already in authorized_keys). Spouses computer, etc.
Right, much easier than a password! And so easy to backup!
I'm not arguing it isn't more secure. The point of this subthread is that SSH keys are not as easy to do ad-hoc as passwords, especially when moving workstations.
It indeed works on Mac OS. I have been using SoloKeys with ed25519-sk keys for about three years now. It should be sufficient to run
ssh-keygen -t ed25519-sk
while a FIDO2 key is connected. You may need to touch the key to confirm user presence. (At least SoloKeys do).
If I recall correctly, the SSH binaries provided by Apple don't have built-in support for signing keys, but if you install OpenSSH from Nix, MacPorts, etc., then you don't have to worry about this.
Another thing to be mindful of is that some programs have a very low timeout for waiting on SSH authentication, particularly git. SSH itself will wait quite a long time for user presence when using a signing key, whereas Git requires me to confirm presence within about 5 seconds or else operations fail with a timeout.
I would like to remind everyone that an internet facing SSH with a password is very unwise. I would argue you need to be able to articulate the justification for it, using keys is actually more convenient and significantly more secure.
Aside from initial boot, I cannot think of the last time I used a password for SSH instead of a key even on a LAN. Support for keys is universal and has been for most of my lifespan.