I Deleted All My SSH Keys and Moved Them Into Hardware
Tired of unprotected key material sitting on disk, the author migrated every SSH key into secure hardware: YubiKeys via ed25519-sk, a TPM through ssh-tpm-agent, and the Apple Secure Enclave on macOS Sequoia. The post walks through generating, enrolling, and using each method, covers unattended setups for services like systemd mount units and SSHFS, and flags the risks of no-touch and PIN-free keys. It also notes that TPM keys are encrypted on disk rather than truly resident.
The theoretical benefit here is that the hardware used to generate the SSH key is needed in order to use the key.
- Bender
I will stick with ssh keys, except that I:
- Put the public authorized keys in /etc/ssh/keys/%u immutable, monitored for checksum changes.
- Have CIDR restrictions in said public keys.
from="x.x.x.x/n,x.x.x.x/n" ssh-ed25519 AAAA[snip] Text-Identifier
- Have NFTables checks for MSS, TCP SYN TTL, Window sizes, CIDR blocks permitted on the public ssh instances (throw away nodes) and behind a VPN on more important roles. If I have a need to keep netfilter disabled then I put sshd behind L4 haproxy with ACL's.
- stryan
Hey I'm in the middle of doing a very similar thing, though I didn't go quite as far as OP. I'm slowly deprecating my old RSA SSH keys and replacing them with a combination of Yubikey, Password Manager, and alternative SSH auth:
1. -sk keys on Yubikeys (with touch enabled) are my primary keys, used for signing and always installed on every host I touch/etc. I initially planned on using the PIV slots on my Yubi's to store the SSH keys instead of the built-in FIDO2 setup, but I hated having to manage multiple moving parts (like getting pscd running on all my clients). The only main benefit of using the PIV slots was being able to set the "cache" touch policy: the YK would cache a touch for up to 15 seconds so doing something like "signing multiple commits during a rebase" would only take one touch instead of num_commits. The side benefit would have been getting to re-use the same SSH key across primary and backup Yubis. The simplicity of the FIDO setup won out and I decided to treat getting annoyed at pressing my Yubikey a bunch of times as a sign I should be doing some sort of alternative setup like a dedicated key. Most prominently, I've now properly setup my Ansible configs with dedicated deploy keys kept as secrets instead of reusing my personal key.
2. I use 1Pass and Bitwarden (work/personal) to store a secondary SSH key that's only used for basic Git auth or other low-risk tasks. This SSH key is loaded from the Password manager directly into ssh-agent via stdin so it nev […]
- mshroyer
YubiKeys with proof-of-presence for SSH auth are great, but I still use the YubiKey's OpenPGP slot for this because my preferred behavior is:
1. Require a PIN followed by touch on the first use after inserting the YubiKey
2. For every following authentication while the key remains connected, only require touch
The extra GnuPG setup needed to make this work is unfortunate, but AFAIK this still isn't possible with fido -sk keys on the YubiKey.
- solyin
How do you break back into your digital life though? You go travelling to a foreign place, get mugged, you don't have your wallet phone or keys. All you have is the grace of a strange letting you use their laptop. How do you get back in?
- moebrowne
I'd use resident keys if it wasn't for the requirement to prepend `no-touch-required` server side, services like GitHub and BitBucket don't support it.
I don't understand why the server should enforce this...
- Magicrafter13
What is the practical/security difference between
`ssh-keygen -t ed25519-sk -O resident -O no-touch-required -O application="ssh:nameyourkey" -f ~/.ssh/id_ed25519-sk`
and
`ssh-keygen -t ed25519-sk -f ~/.ssh/id_ed25519-sk`
?
The latter is what I always do. It creates a file that is useless without my yubikey being present, but is it not actually resident on the key?
- pona-a
I experimented with a YubiKey-only GPG key, with a software backup stored on some thumbdrive. The backup thumbdrive was soon lost, and the key on the Yubikey is now probably expired.
I can't imagine storing my SSH keys on a TPM that might reset them after changing some sticks of RAM changes the hardware measurements or some firmware bug triggers the self-erasure....
- microtonal
Really nice article!
They mention twice that Yubikeys are expensive, but for SSH their cheaper FIDO2 keys work:
https://www.yubico.com/product/security-key-series/security-...