YHK - yet another hacker news clone

I also have a Yubikey but it's been a few years since I tried it for ssh keys. I use it as a regular security key. Maybe I should try it for ssh keys as it sounds like the tooling has improved.

- 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

While this is true, you can create static hierarchy keys that would not resolve into separate key files for the TPM. The issue here is that anyone with access to your TPM can recreate the keys, unless you set a owner password.

https://man.archlinux.org/man/ssh-tpm-agent.1#Hierarchy_keys

I'd rather have qubes than hardware resident keys.

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 never touches my disk; I use fnox to make this backend agnostic.

3. Work uses Teleport, personal uses Tailscale so I rely on those SSH auth most of the time. Nothing much to say here except that Tailscale ssh is really convenient :) .

I've also setup PAM login and sudo on my machines, which brings me back to the old Sun Ray/Smartcard days. None of this is really to prevent security breaches/dedicated attackers or anything, though it certainly makes me harder to compromise. I just wanted to make absolutely sure I couldn't accidentally upload an SSH private key somewhere.

The only way I can get root (short of using a local privilege exploitation exploit to gain root) is by logging, using a Yubikey, over ssh, from a dedicated laptop that has nothing but a SSH client. So the Yubikey is plugged into the laptop.

That dedicated laptop has no wifi drivers and is on a dedicated LAN and that dedicated LAN only has two machines on it: my desktop and that laptop.

The laptop serves no purpose other than: "log in as root on the desktop".

Of course both that laptop and the desktop have firewalls.

This means, yes, I allow log in as root using SSH. But password logins are disabled and the only way to log in as root using SSH is to use the Yubikey. And the firewall only allow SSH attempts to port 22 from the MAC address, IP, and dedicated LAN that corresponds to the laptop.

In addition to that my main desktop has multiple user accounts: but none of those users are allowed to su or sudo.

Now, I know, I could use Qubes or whatever.

But what I explained above is how I do it: even myself I cannot get root on my own desktop without my laptop + Yubikey (I'd need to find and enter the 40 chars long root password).

When I really need to do something as root (and once becoming root becomes extremely hard, suddenly you realize how rare are the occasions when you really need to be root), I open my laptop and boot it (and because that laptop has no GUI and basically nothing besides a SSH client, it boots in three seconds or so).

Haters gonna hate but that's been working totally fine for me since years and years.

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.

They mention twice that Yubikeys are expensive, but for SSH their cheaper FIDO2 keys work:

https://www.yubico.com/product/security-key-series/security-...

`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?

I always worry what do you do when your hardware fails

If you're using userspace software to decrypt the keys into memory then it's all just security theatre. Any sufficiently motivated actor, ot a comprised package in the software chain, can capture your private key as easily as decrypting it from disk. Especially if using ssh-agent that keeps it resident in memory 'for convenience'.

Proper HSM integration with SSH requires challenges signed by the HSM without the private key ever being emitted.