4 ms·

If you're already using a Yubikey, you can use FIDO2-based SSH keys which work natively with ssh-agent.

meepmorp 4y ago
Assuming both client and server are recent enough to recognize the resident key types and are configured to allow them. Source: I have to deal with some machines I can’t fix.
- drdaeman 4y ago
  > I can't fix Do not be afraid! (I've messed with quite a few very ancient and messy systems, like Gentoos of a legal drinking age. Dissected their guts, extracted their hearts, made LD_PRELOAD crutches, containerized stuff to run on modern hardware - this kind of mix of software necromancery and archeology. It's not trivial, but quite doable.) Fortunately, SSH daemons are quite isolated components, so they can almost always be updated without affecting the system. It's possible to build a completely static OpenSSH daemon binary, and replace the ancient /usr/bin/sshd on the most ancient OS. And it will work. Of course, test ahead of time by running your `~/tmp/your-new-sshd -d -p 10022` and ensuring you still can log in. For cleanliness (not to screw the system even further), as long as that machine still has a functional packaging system - even if package repos are long gone, I would recommend wrapping this binary in a OS-native package format (.deb, .rpm or whatever it uses), making a quick-and-dirty backport (from a custom built static binary), and feeding it to the low-level package manager. Preferably, taking a backup of the original sshd package from the local package cache (or finding that exact same package in some online archive). I mean, I've put `sshd`s on all sort of embedded systems, Docker containers and whatnot. Even if you have some Gentoo or Slackware machine from early 2000s (or worse), I don't really see much problem in modernizing an SSH daemon there. The only exception I can imagine is if someone already runs a patched sshd and they can't (or won't risk) backport new stuff in there.
zoidb 4y ago
Also check out https://github.com/FiloSottile/yubikey-agent https://github.com/FiloSottile/yubikey-agent which simplifies the setup quite a bit.

Assuming both client and server are recent enough to recognize the resident key types and are configured to allow them. Source: I have to deal with some machines I can’t fix.

drdaeman 4y ago
> I can't fix Do not be afraid! (I've messed with quite a few very ancient and messy systems, like Gentoos of a legal drinking age. Dissected their guts, extracted their hearts, made LD_PRELOAD crutches, containerized stuff to run on modern hardware - this kind of mix of software necromancery and archeology. It's not trivial, but quite doable.) Fortunately, SSH daemons are quite isolated components, so they can almost always be updated without affecting the system. It's possible to build a completely static OpenSSH daemon binary, and replace the ancient /usr/bin/sshd on the most ancient OS. And it will work. Of course, test ahead of time by running your `~/tmp/your-new-sshd -d -p 10022` and ensuring you still can log in. For cleanliness (not to screw the system even further), as long as that machine still has a functional packaging system - even if package repos are long gone, I would recommend wrapping this binary in a OS-native package format (.deb, .rpm or whatever it uses), making a quick-and-dirty backport (from a custom built static binary), and feeding it to the low-level package manager. Preferably, taking a backup of the original sshd package from the local package cache (or finding that exact same package in some online archive). I mean, I've put `sshd`s on all sort of embedded systems, Docker containers and whatnot. Even if you have some Gentoo or Slackware machine from early 2000s (or worse), I don't really see much problem in modernizing an SSH daemon there. The only exception I can imagine is if someone already runs a patched sshd and they can't (or won't risk) backport new stuff in there.

zoidb 4y ago

Also check out https://github.com/FiloSottile/yubikey-agent https://github.com/FiloSottile/yubikey-agent which simplifies the setup quite a bit.