Trezor SSH Keys on macOS

You want to log into your servers with a key that lives on a physical device, not a file sitting on your Mac's disk. A Trezor can do that. Two different ways, actually. But there is a catch that trips almost everyone on the first attempt, and it is pure Apple: the ssh that ships with macOS physically cannot talk to a FIDO2 security key. Run the obvious command and it dies before it does anything.

Before you touch anything, run one command:

ssh-keygen -t ecdsa-sk

On a stock Apple build this prints unknown or unsupported key type ecdsa-sk and quits. If you are on Tahoe and it does not error, Apple may have flipped the flag and you can skip the Homebrew step. One warning: if you have seen headlines about Secure Enclave SSH keys in macOS 26, that is a different feature. It makes a key inside the Mac's own chip, and it is not support for an external device like a Trezor.

Method A: A FIDO2 SSH key (ecdsa-sk)

This is the "SSH already knows how to do this" method. OpenSSH 8.2 added native support for FIDO/U2F security keys, and a Trezor is a FIDO2 device. The key type is ecdsa-sk: an ECDSA key whose private half never leaves the hardware. The catch is that Apple ships OpenSSH with that support removed, so on macOS you have to bring your own.

Step 1: Install Homebrew's OpenSSH

Homebrew's formula is built with security-key support on and pulls in libfido2 automatically:

brew install openssh

Now make the shell use Homebrew's binaries instead of Apple's. On Apple Silicon they live in /opt/homebrew/bin, so put that first on your PATH:

export PATH="/opt/homebrew/bin:$PATH"
which ssh-keygen   # should say /opt/homebrew/bin/ssh-keygen, not /usr/bin

Step 2: Get Apple's ssh-agent out of the way

macOS auto-starts Apple's own ssh-agent through launchd and sets SSH_AUTH_SOCK to point at it. That agent cannot handle sk-keys, so it will quietly break things. The clean workaround is to unset the variable in your shell:

unset SSH_AUTH_SOCK

Or point SSH_AUTH_SOCK at a Homebrew ssh-agent you start yourself. Do not bother trying to disable Apple's agent at the system level: editing that launchd plist is blocked by System Integrity Protection.

Step 3: Generate the key

One Trezor-specific detail that catches everyone: quit Trezor Suite first. If Suite is open it holds the device, and the FIDO operation just fails. With Suite closed and the Trezor plugged in over USB:

ssh-keygen -t ecdsa-sk -O verify-required

Touch and confirm on the device when it asks. This writes ~/.ssh/id_ecdsa_sk (the handle) and ~/.ssh/id_ecdsa_sk.pub (the public key). A few things worth knowing:

• Trezor does ecdsa-sk only. It supports the NIST P-256 ecdsa-sk type and not ed25519-sk. Enrolling an ed25519-sk key on a Trezor fails, and the feature request is closed as not-planned. If you need Ed25519 FIDO2 keys, that is a Nitrokey or a YubiKey, not a Trezor. More on that below.
• Use a non-resident key, which is the default. The id_ecdsa_sk file is not your private key. It is a credential handle, a pointer that is useless without the physical Trezor. Back it up, but back it up per machine, because it is tied to this enrollment.
• Skip resident keys for now. Keys stored on the device itself have a history of Trezor firmware bugs. Not worth it yet.
• -O verify-required makes the server insist on a PIN or touch check at login, not just device presence. That option needs OpenSSH 8.3 or newer, and Homebrew's build is well past that.

Step 4: Install the key and connect

Copy the public key to the server's ~/.ssh/authorized_keys, the same as any other SSH key:

ssh-copy-id -i ~/.ssh/id_ecdsa_sk.pub [email protected]
ssh [email protected]   # touch the Trezor to confirm the login

Which Trezor works: the Safe 3, Safe 5, and Safe 7, plus the older Model T, all speak the FIDO2 applet in the universal firmware over USB. If you are shopping for one, any of those works: buy direct from Trezor (affiliate link, see our disclosure). The Model One is U2F-only, and the docs conflict on whether ecdsa-sk works there, so treat it as "may work, untested." Our Trezor notes cover the model differences.

Method B: trezor-agent

The other approach ignores OpenSSH's FIDO support entirely. trezor-agent is a separate tool, actively maintained with releases as recent as March 2026, that turns your Trezor into an SSH agent. Instead of a FIDO2 credential, it derives an SSH key deterministically from your wallet seed.

Install

brew install trezor-agent
brew install libusb   # only if the USB backend is missing

Or install it with pipx if you prefer to keep Python tools separate.

Use it

Keys come from your seed, one per "identity string" (usually a hostname or a URL). Export a public key for an identity, and note that this method supports Ed25519:

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

Then connect through the agent for a session:

trezor-agent user@host -c

One config gotcha will waste your afternoon: IdentitiesOnly yes tells ssh to use only the key files named in your config and ignore anything an agent offers, so it skips the trezor-agent key. If you have that line in ~/.ssh/config, set IdentityFile to the exported .pub so the agent key still matches:

Host myserver
  HostName server.example.com
  User you
  IdentityFile ~/.ssh/github.pub

The real selling point: the keys are portable. Because they are derived from the seed, you never back up a key file. Restore the seed on any machine and the exact same SSH keys come back. Nothing else to save.

One honest hedge on hardware support: the trezor-agent README documents the Trezor One and Model T (alongside Jade, OnlyKey, and others). The newer Safe series is not explicitly listed. So this is documented for the older models. If you have a Safe, expect it to work but verify against your own device before you rely on it.

Which method should you pick?

They are not equivalent, and the difference is about your coins.

Method B ties your SSH identity to the same seed that guards your cryptocurrency. A leaked seed means both your funds and your server logins are compromised at once. Using the device daily for SSH also means exposing that seed to more moments where something could go wrong. Method A is cleaner on this front: a FIDO2 ecdsa-sk credential lives in a separate applet and is not derived from your wallet seed at all. Compromising your logins does not touch your coins, and vice versa. If you want to think harder about why one seed guarding two very different things is a real trade-off, read our piece on hardware 2FA, FIDO2, and the one-seed problem.

So, plainly:

• Pick Method A if you want seed separation and mostly-standard tooling, once Homebrew's OpenSSH is in place. The cost is ecdsa-sk only on a Trezor, and the one-time macOS setup dance.
• Pick Method B if you want seed-portable identities and Ed25519 keys, and you are comfortable that your SSH key and your wallet share a root.

Method A is not Trezor-only, and this is where it gets useful. The exact same Homebrew-OpenSSH path works with a Nitrokey 3, and the Nitrokey does ed25519-sk: the key type a Trezor refuses. We run both here, Trezor Safe devices and Nitrokeys, depending on the machine. If you want FIDO2 seed separation and Ed25519 at the same time, a Nitrokey 3 is the answer. Our hardware security key comparison lays out the full set of trade-offs.

If you do not own a device yet, a Trezor Safe from the current lineup covers Method A cleanly, with the seed-separation win baked in.

On Linux and Windows

The macOS problem is specifically Apple's build choice. On other systems the setup differs (usually no Homebrew-OpenSSH detour), so if you switch machines see our companion guides for Trezor SSH on Linux and Trezor SSH on Windows.

Resources

• OpenSSH 8.2 release notes (the release that added FIDO/U2F security-key support)
• Trezor: SSH with your Trezor
• trezor-agent: SSH README
• Homebrew formula: trezor-agent
• Homebrew formula: libfido2