Enable Touch ID for sudo and SSH Authentication on macOS

What you'll build

By the end of this tutorial, sudo commands in Terminal will prompt for Touch ID instead of a password, and your SSH private key will live in the Secure Enclave, unlocked with a fingerprint scan every time you connect to a remote host.

These are two separate mechanisms solving two different problems, so we'll set them up one at a time.

Prerequisites

• A Mac with a physical Touch ID sensor: MacBook Pro/Air (2016+) or a desktop Mac paired with a Magic Keyboard with Touch ID.
• macOS Ventura or later recommended (examples below work on Monterey too, with one small difference noted in Step 1).
• Homebrew installed, for the SSH agent app.
• Admin rights on the Mac (you'll be editing files under /etc/pam.d/).
• Basic comfort with sudo, ssh-add, and editing ~/.zshrc or ~/.bash_profile.

Check your macOS version first:

sw_vers -productVersion

Step 1: Enable Touch ID for sudo

Apple ships a PAM module called pam_tid.so that hooks into the Secure Enclave for local authentication. The tricky part isn't enabling it, it's making the change survive the next macOS update.

Check whether your system has the newer template file:

ls /etc/pam.d/sudo_local.template

If the file exists (recent macOS versions), use it. It's included by /etc/pam.d/sudo automatically and, unlike editing sudo directly, it isn't wiped out by system updates:

sudo tee /etc/pam.d/sudo_local <<'EOF'
# sudo_local: local config file which survives system update and is included for sudo
auth       sufficient     pam_tid.so
EOF

If the template doesn't exist (older macOS), edit /etc/pam.d/sudo directly instead:

sudo cp /etc/pam.d/sudo /etc/pam.d/sudo.bak
sudo nano /etc/pam.d/sudo

Add this as the very first line, above everything else already there:

auth       sufficient     pam_tid.so

Save with Ctrl+O, Enter, then exit with Ctrl+X. Keep the backup around in case a future OS update clobbers this file, you'll need to reapply the change (this is exactly why Apple introduced sudo_local).

Step 2: Verify sudo Touch ID works

Clear any cached sudo credentials so you get a fresh prompt, then test:

sudo -k
sudo whoami

You should see a small system dialog asking for Touch ID (or password as a fallback) instead of a plain text password prompt. Scan your fingerprint, and the command should print root.

Step 3: Install a Secure Enclave SSH agent

pam_tid only covers local authorization (sudo, some System Settings panes). It has nothing to do with SSH keys. For that, you need your private key generated inside the Secure Enclave, where it can never be exported, and an SSH agent that asks Touch ID to authorize each signing operation.

Stock OpenSSH on macOS doesn't support Secure Enclave keys natively. The tool that does this well, and is actively maintained and notarized, is Secretive:

brew install --cask secretive

Launch it:

open -a Secretive

Step 4: Generate a Secure Enclave-backed key

In the Secretive window, click the + button to create a new key. Give it a name (e.g. personal-laptop), leave the type as the default Secure Enclave key, and confirm. Secretive can require Touch ID (or Apple Watch) per-key, on by default.

Secretive runs its own SSH agent process and exposes a Unix socket. Point your shell at it by adding this to ~/.zshrc (or ~/.bash_profile if you're still on bash):

echo 'export SSH_AUTH_SOCK="$HOME/Library/Containers/com.maxgoedjen.Secretive.SecretAgent/Data/socket.ssh"' >> ~/.zshrc
source ~/.zshrc

Confirm the agent sees your new key:

ssh-add -l

You should see a single entry with a fingerprint (SHA256:...) and the key name you chose, listed as an ECDSA key (Secure Enclave keys are always P-256 ECDSA, there's no RSA or Ed25519 option here, that's a hardware limitation).

Step 5: Deploy the public key

In Secretive, select your key and use the copy button (or right-click) to copy the public key to your clipboard. Then append it to authorized_keys on the remote host:

pbpaste | ssh user@remote-host 'mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys'

Now connect:

ssh user@remote-host

Secretive intercepts the signing request and pops a Touch ID prompt before the connection completes.

Verify it works

Run through this checklist:

1. sudo -k && sudo whoami prompts Touch ID and returns root.
2. ssh-add -l lists your Secure Enclave key without you having unlocked anything manually.
3. ssh user@remote-host triggers a Touch ID prompt and logs you in with no password.
4. echo $SSH_AUTH_SOCK points to the Secretive container path, not /tmp/launch-... (the default macOS agent socket).

If all four hold, you're done.

Troubleshooting

Touch ID prompt never appears in tmux or screen. This is a known limitation, not a config mistake. pam_tid needs a direct session context tied to the Secure Enclave that detached/multiplexed sessions don't provide. It falls back to a password prompt inside tmux panes. Run sudo commands from a plain Terminal or iTerm2 tab outside tmux if you need Touch ID specifically.

Sudo Touch ID worked, then broke after a macOS update. If you edited /etc/pam.d/sudo directly (the legacy method), a system update can overwrite it. Check with cat /etc/pam.d/sudo and reapply your line if it's gone, or better, migrate to the sudo_local approach in Step 1, which is designed to survive updates.

Touch ID doesn't work when I sudo after SSHing into this Mac. Expected behavior. There's no physical Touch ID sensor to check over a remote session, so pam_tid silently falls through to password auth for remote logins. This isn't fixable from config, it's how the Secure Enclave check works.

ssh-add -l returns "The agent has no identities." Almost always a SSH_AUTH_SOCK mismatch. Run echo $SSH_AUTH_SOCK and confirm it matches the Secretive container path from Step 4, and confirm Secretive is actually running (check the menu bar icon). If you use multiple terminal apps or shells, make sure the export line is in the profile each one sources.

Permission denied (publickey) on the remote host. Check permissions on the remote end: chmod 700 ~/.ssh and chmod 600 ~/.ssh/authorized_keys. SSH refuses to use keys if the directory or file permissions are too open.

Next steps

Read through Secretive's own README for details on per-key Touch ID vs. Apple Watch requirements and how it handles git commit signing with SSH keys. If you manage multiple machines, look at 1Password's SSH agent, which offers similar biometric-gated signing but syncs keys across devices through the password manager instead of pinning them to one Mac's hardware. And if you need something that works identically across macOS, Linux, and Windows, a hardware FIDO2 key generating resident SSH keys (ssh-keygen -t ed25519-sk) gets you the same physical-presence guarantee without relying on any one vendor's software.