Mastodawn

Generating and storing #SSH keys inside the #TPM (Trusted Platform Module)

https://linderud.dev/blog/store-ssh-keys-inside-the-tpm-ssh-tpm-agent/

It works, at least on a Thinkpad X1 and Debian 12. I'm not sure I'd actually prefer that to something more portable such as a Yubikey.

I'm interested in hearing your feedback, and whether you actually use the TPM (and what for).

Store ssh keys inside the TPM: ssh-tpm-agent

After writing age-plugin-tpm a friend of mine at the hackerspace was super excited to finally have easy file encryption with TPM sealed keys, all without having to rely on gnupg. “This is great!” he said. “I wish I could have my SSH keys sealed in a TPM just as easily”. We should have left it at that. I shouldn’t have replied with a random assortment of facts like “I know google/go-tpm now”, or “but Go has a ssh-agent protocol implementation” followed-up with “Filippo has already implemented yubikey-agent, it can’t be that hard”. So I wound up writing a new ssh agent.

Morten Linderud

`ssh host whoami` takes just over 1 second longer when using a TPM-backed SSH key than when using the same key algorithm in a file on the file system.

DrScriptt 2d ago

@jpmens I’m not surprised by that.

I suspect that the security trade off warrants it, especially for headless servers to have the private part of the key in hardware that it can’t be extracted from.

Maybe not ideal for interactive use.

But could be better if TPM key didn’t have a passphrase requirement and a local file did require a passphrase.

Assuming corporate security scans all keys and flags any without a passphrase on them.

Zaͩnͦsͤt̀́rͤa̅̆̈3d ago

@jpmens I'm using the SecureEnable on my MacBook Pro, probably something similar.

https://secretive.dev

Secretive

Protect your SSH Keys using your Mac's Secure Enclave.

@jpmens I don't really think it needs to be mutually exclusive with a Yubikey... e.g. I have a TPM key for SSH on one system *and* a Yubikey as a portable carrier *and* an eToken 5110 inside another system – and the rest of my security is still "yolo" level, really, but there are some things that the portable Yubikey isn't authorized to directly access while the laptop's key is, for example.

The `ssh` taking 1 second longer might be a hardware difference. On my ThinkPad it's 0.5s in total when using a TPM-backed RSA2048 key (it's not EC for silly reasons but I can't imagine EC being much slower).

Might also be a difference in which parent TPM key that SSH key was created under. Tradition carried over from TPM1 era is to generate a persistent root key (SRK) and store it in the TPM, so my test key is stored using the rough equivalent of "ssh-tpm-agent --parent-handle 0x81000001" (which is the agreed default handle for a SRK). At some point systemd-cryptsetup used a transient ECDSA SRK that it would generate deterministically each and every time. I'm not sure what ssh-tpm-agent does exactly, but I wonder if it might be using a transient parent key or something, which adds to the time needed to load the child key?...

پویان Pouyan 3d ago

@jpmens I’m using FIDO passkeys with non-resident keys:

https://blog.pouyan.net/en/post/2026/2026-01-07-how-to-setup-ssh-keys-on-yubikey/

The downside is that I have to enter the pin everytime.

#fido #ssh #yubikey

Setup SSH Authentication using FIDO2 Keys (Passkeys) on a Yubikey

I wanted to secure my SSH keys using a Hardware token, a series of bugs and config complications proved that it is harder than I thought.

Quaintous

@jpmens doesn't TPM access require root privileges? Is there user friendly way to use it as an ordinary user?

@pemensik from [1] I learned to `usermod -G tss $USER'

[1] https://jade.fyi/blog/tpm-ssh/

Using a TPM 2.0 to secure ssh keys

computers i guess

@jpmens Interesting. Is there a limit of keys number, which I can store into my TPM 2.0 chip? I think I would like a local root service a bit more, talking by unix domain socket to local users. But nobody wrote anything similar and I won't have time to do that soon myself. Found about half year ago, practical using of TPM on Linux is very sparsely documented for mere mortals.

@pemensik https://news.ycombinator.com/item?id=36922323

How many keys can I store inside a laptop's TPM? Is there a limit? I have hundre... | Hacker News

@jpmens I wish systemd-credentials was somehow merged with this usage style. So I can have as many keys for as many users on local system, but encrypted by some key stored in the TPM.

That information is great, but on very obscure domain. I think it should deserve some text file in actual packages providing such functionality.

Christophe Brocas

@jpmens what about if your motherboard failed to restart? Keys are linked to it and non extractable before an eventual problem, right?
If it is the case, portable and duplicable yubikeys have my favor.

@jpmens
I'm using it both in my home lab as a PoC and (so far, only experimentally) in my day job. We've gotten to the point now where exfiltration of keys is table stakes if an attacker gets into your environment, so I'm a big fan of hardware-bound keys. A yubikey is technically better, imo, but the UX when you've got less-security-focused-users is just better if the key is built into the machine they're provided with.

@iMeddles interesting. Does that mean you pre-generate keys for laptop/desktop users, and if I may ask, passphrase-less?

@jpmens
At present, yes, while it's experimental, but the eventual design I want to get to once the tooling is a *little* more mature would get rid of pre-generation and render passphrases moot.

(Warning: wall of text incoming in next reply with design details :p)

@jpmens
The design I *want* to get to in order to roll this out as non-experimental combines the tpm-bound ssh keys with short-lived (<24hr) SSH certificates, alongside device attestation (to prove a given ssh key is on a tpm, no matter who or when it was generated).

The background flow I'm working on, for which we *almost* have all the tooling, is: every day a script notices the user doesn't have a valid ssh certificate, and so generates a new CSR for the key, alongside an attestation statement. The SSH CA validates the attestation statement is correct for the laptop that that user was issued (and API calls out to the Device Management System to check that the device is compliant with all our policies) before issuing the certificate. Access to the CA is gated behind an SSO login, which enforces a daily check that the user is still valid and hasn't been suspended.

Thus the UX for the end user is minimally changed (one SSO login gets enforced per day, but otherwise they ssh and git in the manner they're used to, without them needing to change any behaviour - in fact as they never have to worry about copying their SSH publeys around, it's likely easier for the end user overall); whilst for us in Sysadmin we get loads of upsides:

1. No longer having to care about managing and clearing out authorized_keys files as they don't exist thanks to the certs
2. Guarantees that a given ssh login was initiated from a device that has our security policies applied to it
3. the knowledge that if we have to suspend a user for any reason, all their SSH access will be gone either as soon as the device management system locks their computer out (if their computer is online) or as soon as the ssh certificate expires if not
4. We can leverage the TPMs ability to measure boot to stop a user even starting the process of getting access if the operating system or the system boot settings have been tampered with.

It's definitely a system with a bunch of complexity, but when you're in an Organisation context it has a lot of nice upsides as a trade off for that.

@iMeddles it’s late here, and I’m tired, but I will try and process/understand tomorrow. Thank you for your insights!

@jpmens
No problem, I'm very happy to answer any questions about this - I'm still trying to make sure I've got all the pieces straight in my head, and answering questions is the best way to find the gaps in my own knowledge!