Trezor as an SSH Key on Linux

Your SSH private key is a file. It sits in ~/.ssh, readable by anything running as you. Steal the laptop, copy the key, and every server that trusted it is now theirs too. A passphrase slows that down. It does not stop malware that logs your keystrokes. The real fix is to put the private key somewhere a thief cannot copy it: inside a hardware device that signs each login and never hands the secret over. You already own one if you have a Trezor. Here are two ways to wire it up on Linux, both real, and how to pick.

On macOS or Windows instead? See our Trezor SSH on macOS and Trezor SSH on Windows guides. The commands differ; the trade-offs below are the same.

Method A: OpenSSH FIDO2 Key (Start Here)

Modern OpenSSH can talk to a security key directly. No agent, no wrapper, just ssh-keygen and a device tap. You need OpenSSH 8.2 or newer with security-key support, plus libfido2 1.3.0 or newer. Check your client:

ssh -V

Install libfido2 from your distro if it is missing (it is packaged as libfido2 on Debian, Ubuntu, Fedora, and Arch). The server you log into also needs OpenSSH 8.2 or newer, because it has to understand the sk-ecdsa key types.

Install the udev Rules

Linux will not talk to the Trezor without udev rules. Use the official trezor-udev package, or drop the rules in by hand:

sudo curl https://data.trezor.io/udev/51-trezor.rules -o /etc/udev/rules.d/51-trezor.rules
sudo udevadm control --reload-rules && sudo udevadm trigger

Generate the Key (ecdsa-sk Only)

Read this part carefully, because it is the one place people waste an hour. Trezor supports ecdsa-sk (NIST P-256) and nothing else. If you try the newer ed25519-sk, enrollment fails with "Key enrollment failed: invalid format." That is not your mistake. The feature request to add it was closed as not planned. (Nitrokey 3 and YubiKey do support ed25519-sk, more on that later.) So on a Trezor, the command is:

ssh-keygen -t ecdsa-sk -O application=ssh:myserver -O verify-required -f ~/.ssh/id_ecdsa_sk

Two options earn their keep here. -O application=ssh:myserver gives this credential a distinct name, so you can mint one per purpose instead of reusing a single key everywhere. -O verify-required forces a PIN or touch on every use rather than mere presence (this one needs OpenSSH 8.3 or newer). Confirm the action on the Trezor screen when it prompts.

Stick with non-resident keys, which is the default. The file it writes, ~/.ssh/id_ecdsa_sk, is not the secret. It is a credential handle: useless to a thief without your physical device plugged in and unlocked. The catch is that the handle is tied to that one enrollment, so back the file up and copy it to every client machine you want to log in from. Lose it and you re-enroll. You can make resident keys instead (-O resident, later pulled off the device with ssh-keygen -K), but resident keys have a history of bugs with Trezor. We recommend against them for now.

Copy the Public Key to Your Servers

ssh-copy-id -f -i ~/.ssh/id_ecdsa_sk.pub user@your-server
# or paste the contents of id_ecdsa_sk.pub into ~/.ssh/authorized_keys by hand

Now log in. The device lights up, you confirm, you are in. The private key never left the hardware.

Which Trezors work? FIDO2 runs on the Safe 3, Safe 5, Safe 7, and the Model T, all needing current universal firmware, over USB only. The older Model One is U2F-only, and Trezor's own docs disagree on whether non-resident ecdsa-sk works there, so treat it as may-work, untested. Buying for this? A Safe device Trezor is the safe bet (affiliate link, see our disclosure). Full model notes live on our Trezor resource page.

Method B: trezor-agent (The Deterministic Alternative)

The other route is trezor-agent, a small SSH agent that lives in front of the device. It is actively maintained, with releases as recent as March 2026. Install it in an isolated environment:

pipx install trezor-agent
# or: pip3 install trezor-agent

On Debian and Ubuntu you will want the build dependencies first, plus the same udev rules from Method A:

sudo apt install python3-pip python3-dev libusb-1.0-0-dev libudev-dev

Here is the part that makes trezor-agent different. Its SSH keys are derived deterministically from your wallet seed, one key per identity string like user@host. There is no key file to guard and no handle to lose. Restore your seed onto a new device and the exact same SSH keys come back. It also supports Ed25519, the key type Method A cannot give you on a Trezor.

Export a public key for a service, then connect:

trezor-agent -v -e ed25519 [email protected] > ~/.ssh/github.pub
trezor-agent user@host -c

One config trap: IdentitiesOnly yes in your SSH config makes ssh ignore agent-provided keys, and trezor-agent's keys come from the agent. If you use that setting, point IdentityFile at the exported .pub so ssh still offers it.

Device support needs an honest caveat. The trezor-agent README lists the Trezor One and Model T (alongside other hardware like Jade and OnlyKey). The Safe series is not explicitly listed. The method is documented for the older models and reported working through the same underlying library, but verify it with your own Safe device before you rely on it for anything you cannot afford to be locked out of.

Which One Should You Use?

This is the choice that actually matters, and it is not about convenience. It is about what your SSH key is welded to.

Method B couples your SSH identity to the same seed that guards your coins. A leaked seed then compromises both at once, and using that seed for day-to-day SSH logins raises its operational exposure: it comes out of the drawer far more often. Method A's FIDO2 credentials sit in a separate applet on the device and are not derived from the seed at all. If the SSH side is somehow compromised, your recovery seed stays untouched. We dig into why one-seed-for-everything is a real risk in hardware 2FA, FIDO2, and the one-seed problem.

The Same Trick With a Nitrokey

Method A is not Trezor-specific. It works with a Nitrokey 3 too, and the Nitrokey also does ed25519-sk, so you get the newer key type that Trezor refuses. Grab the udev rules from Nitrokey's repo instead of Trezor's, then run the same ssh-keygen flow (you can use -t ed25519-sk here). We run both around here: Trezor Safe devices and Nitrokeys, and reach for each depending on the machine. If you are weighing devices, our hardware security keys comparison lays out the differences.

Resources

• OpenSSH 8.2 release notes (FIDO/U2F security-key support)
• Trezor: SSH with Trezor
• trezor-agent: SSH usage documentation
• Trezor: udev rules for Linux
• Nitrokey: FIDO2 SSH keys