Best SSH key manager for Mac developers in 2026: 1Password SSH Agent

1Password SSH Agent is the answer for most Mac developers. It keeps your SSH keys in an encrypted vault, requires Touch ID for every authentication, and handles git commit signing via op-ssh-sign without touching a config file by hand. The $2.99/month individual plan covers all of it. If the subscription is a dealbreaker, Bitwarden’s free SSH agent covers the basics with less community documentation. If you’re macOS-only and want hardware-backed keys that cannot be exported under any circumstances, Secretive is the tool for that one narrow case.

Plain ssh-agent with keys on disk is adequate for a single machine with no forwarding and no team members. That covers fewer situations than most developers think.

Who this is for

Mac developers who manage three or more SSH hosts and currently store keys as plaintext files in ~/.ssh/. If you’ve already bought 1Password for passwords and want to know whether adding SSH to it makes sense — it does. The SSH agent is the same subscription, same vault, same app. If free is a hard requirement, start with the Bitwarden section.

What we tested

Tool	Version	Platform
1Password SSH Agent	8.10.x	macOS Sequoia 15.x, Ubuntu 24.04
Bitwarden SSH Agent	v2025.1.2 (Jan 2025)	macOS Sequoia 15.x
Secretive	3.0.4	macOS Sequoia 15.x
Plain ssh-agent	OpenSSH 9.8	macOS Sequoia 15.x

Machine: M-series MacBook Pro, 16 GB RAM, macOS Sequoia 15.x.

Tested end-to-end: key generation, SSH auth to a remote Linux host, git commit signing including the GitHub “Verified” badge, DevContainer usage on macOS, and key import from existing OpenSSH format.

The threat you’re actually solving for

Most developers have ~/.ssh/id_ed25519 sitting unencrypted on disk with no passphrase. Any process running as your user can read it — malware, a compromised npm install script, a tool you ran off a GitHub README.

Agent forwarding makes this worse. When you ssh -A to a jump host, root on that host can use your agent socket while your session is open. Your keys authenticate anywhere they’re authorized, silently, without your knowledge.

The fix has four parts:

Keys stored encrypted, not as plaintext files on disk.
Touch ID per use — biometric confirmation that a human approved this specific operation.
Git commit signing — proves a commit came from you, not from anyone who has push access.
Team sharing — deployment keys shared via a vault instead of emailed .pem files.

SSH key managers solve all four. The question is which one fits your situation.

1Password SSH Agent

1Password SSH Agent launched in 2022 and supports Ed25519 and RSA (2048, 3072, 4096 bit). No DSA, no ECDSA — intentional, not an oversight.

Setup: In 1Password Settings → Developer, enable the SSH agent. Add this to ~/.ssh/config:

Host *
  IdentityAgent "~/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock"

Generate or import keys in the 1Password vault, then add the public keys to GitHub or your servers. That covers the core setup.

Touch ID per operation: Every ssh invocation triggers a Touch ID or Apple Watch prompt. You see which key is being used, which host is requesting it, and you approve or deny explicitly.

Git commit signing: The “Configure Commit Signing” button in 1Password’s SSH key item writes your .gitconfig entries automatically — gpg.format = ssh, user.signingKey, gpg.ssh.program. It sets op-ssh-sign (at /Applications/1Password.app/Contents/MacOS/op-ssh-sign) as the signing binary. After that, git commit -S and GitHub’s “Verified” badge work without further config.

Cross-platform: macOS, Windows, Linux (native packages — not Flatpak or Snap). Linux users set SSH_AUTH_SOCK to the 1Password socket path manually; the docs cover this in detail.

Where it creates friction:

DevContainers and WSL: The agent socket doesn’t forward into containers automatically. You need a socat bridge or the op ssh CLI wrapper to expose the agent inside the container. Plan for this before deleting your disk keys — test authentication from inside the DevContainer first.
Touch ID focus issue: On macOS Sequoia, the Touch ID dialog occasionally fails to focus after screen lock. The workaround is clicking the 1Password icon in the menu bar. It’s a known issue.
Six-key server limit: Servers enforcing MaxAuthTries 6 won’t try keys past the sixth. If your vault has more than six keys, pin the right one per host in ~/.ssh/config with IdentityFile.

Teams and enterprise: 1Password vault sharing handles deployment keys. Put a deploy key in a shared vault, and anyone with vault access can use it through their own Touch ID. 1Password Business adds SCIM, SSO, and Secrets Automation for CI/CD pipelines. At $7.99/user/month (annual), it’s not cheap — but it replaces the “email the .pem file” workflow that every team eventually regrets.

Bitwarden SSH Agent

Bitwarden added SSH agent support in v2025.1.2 (January 2025). The free tier includes it. Setup mirrors 1Password: enable in Bitwarden Settings → SSH Agent, point IdentityAgent at Bitwarden’s socket, add public keys to your servers.

Bitwarden generates Ed25519 keys only. RSA import works, but you can’t generate RSA in-vault. For most developers Ed25519 is the right default anyway.

What it lacks: The gap isn’t features, it’s documented experience. 1Password’s SSH agent has been in production since 2022. Bitwarden’s has been out since January 2025. When you hit a weird edge case — DevContainer socket forwarding, shared vault keys not appearing in the agent, WSL2 setup — StackOverflow answers and community blog posts are sparse compared to 1Password.

One important note: Bitwarden for macOS is not available via the App Store. Install from bitwarden.com or via Homebrew.

Where Bitwarden wins: It’s free. If you’re a solo developer, you’re not sharing keys across a team, and $2.99/month is the deciding factor — Bitwarden does the job.

Secretive

Secretive is an open-source macOS app that stores SSH keys in the Secure Enclave. The keys are 256-bit ECDSA (P-256) — the Secure Enclave’s hardware constraint, not Secretive’s choice. They cannot be exported, backed up, or moved to another machine.

If you switch Macs, you regenerate keys. If your Mac breaks before you migrate, your keys are gone. Every server and service authorized to a Secretive key needs to be re-authorized from scratch.

This sounds like a downside and usually is. The upside: the Secure Enclave enforces this at the hardware level. No software process running on your Mac can extract the private key. Not malware, not a kernel exploit, not root. The key exists only in the secure processor.

The right case for Secretive: You’re macOS-only, you manage your own servers, you never share keys, and you want the strongest possible hardware guarantee. This is a narrow case. For most developers managing multiple hosts across personal and work infrastructure, the portability trade-off doesn’t pay.

Maintenance note: Secretive v3.0.4 (November 2025), maintained by one developer. The project is active but not a company-backed product.

Plain ssh-agent

ssh-agent is preinstalled on every macOS and Linux machine. Keys are unencrypted in memory while the agent is running. No Touch ID, no biometric confirmation, no notifications when a key is used.

Agent forwarding (-A) is common and risky. Root on the remote host can use your forwarded agent socket while your session is open. This is a documented, actively exploited attack class — not a theoretical concern.

The argument for plain ssh-agent: simplicity. No software to install, no subscription, no daemon to debug. One machine, one server, no team, no forwarding — it’s defensible.

If you stay on plain ssh-agent, use an encrypted key and store the passphrase in macOS Keychain:

ssh-keygen -t ed25519 -C "[email protected]"
# enter a strong passphrase when prompted
ssh-add --apple-use-keychain ~/.ssh/id_ed25519

This protects keys at rest without fixing the agent forwarding exposure.

Feature matrix

	1Password	Bitwarden	Secretive	Plain
Ed25519 generation	✅	✅	❌ (P-256)	✅
RSA import	✅	✅	❌	✅
Touch ID per use	✅	✅	✅	❌
Team sharing	✅ vault	✅ vault	❌	❌
Cross-platform	Mac/Win/Linux¹	Mac/Win/Linux¹	macOS only	Universal
Git commit signing	✅ op-ssh-sign	✅	✅	✅ (manual)
Key backup/portability	✅ vault	✅ vault	❌ hardware	✅ file
Cost	$2.99+/mo	Free–$10/yr	Free	Free

¹ Native packages only. Not Flatpak, not Snap, not Mac App Store (Bitwarden).

Verdict

Solo developer on macOS: 1Password SSH Agent at $2.99/month individual. Best documentation, smoothest git commit signing setup, works on Mac and Linux without changes.

Small team with shared deployment keys: 1Password Teams at $7.99/user/month. Shared vault with Touch ID for each member, audit log, no emailed key files.

Budget solo developer: Bitwarden free tier. Does the job. Expect less community help on edge cases.

macOS-only, maximum hardware security, no portability needed: Secretive. A narrow but legitimate use case.

Single machine, no forwarding, no team: Plain ssh-agent with an encrypted Ed25519 key and Keychain-stored passphrase. Upgrade when your situation changes.

Setting up 1Password SSH Agent

In 1Password: Settings → Developer → enable SSH Agent.
Edit ~/.ssh/config:

Host *
  IdentityAgent "~/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock"

In 1Password: New Item → SSH Key → generate Ed25519. Name it after what it authenticates (“GitHub”, “prod-bastion”).
For git commit signing: open the SSH key item in 1Password → click “Configure Commit Signing.” It writes your .gitconfig entries automatically.
Copy the public key from the item and add it to GitHub under Settings → SSH and GPG keys — once as an Authentication Key, once as a Signing Key.
Test authentication: ssh -T [email protected]. The 1Password Touch ID prompt should appear.

For shared vault keys (Teams): Keys in shared vaults don’t load by default. Edit ~/.config/1Password/ssh/agent.toml:

[[ssh-keys]]
vault = "Shared"

Without this, 1Password only loads keys from Personal vaults.

Migrating existing keys into 1Password

1Password imports OpenSSH format, PKCS#8, and PKCS#1. It does not import PuTTYgen .ppk files or DSA/ECDSA keys. Convert before importing, or stay on the RSA key you have.

Safe migration sequence:

# Confirm 1Password is serving keys
ssh-add -l
# should list your keys with source noted as 1Password

# Add the 1Password public key to each server
ssh-copy-id -i /path/to/1p-key.pub user@host1
ssh-copy-id -i /path/to/1p-key.pub user@host2

# Test each host — Touch ID prompt should appear
ssh user@host1
ssh user@host2

# After confirming every host works, remove disk copies
rm ~/.ssh/id_ed25519 ~/.ssh/id_ed25519.pub

Do not delete disk keys until you’ve tested every host you care about. It takes ten minutes to be thorough and hours to recover from a misconfiguration on a host you access infrequently.

DevContainer note: Set up the socat bridge or op ssh CLI wrapper and test inside the container before removing disk keys. The container environment is the most common place migration breaks silently.

Caveats

This article contains an affiliate link to 1Password. We tested the product independently. If Bitwarden had been the clearly better tool for the primary use case, we’d have recommended it instead — the free tier is genuinely good.

We didn’t test 1Password on Windows beyond basic verification. The DevContainer socket bridging issues were reproduced on macOS Sequoia; Windows/Linux behavior may differ.

Bitwarden’s SSH agent is less than two years old as of this writing. Edge case behavior may improve significantly with updates.