1Password SSH Agent: Keep Private Keys Out of Git Tools

A private SSH key copied across laptops, Git clients, shell profiles, and backup folders becomes hard to inventory and revoke. The 1Password SSH agent offers a different model: the client asks the desktop app to sign, while the private key stays inside 1Password.

If you are still choosing a team plan, use the 1Password Teams vs Business calculator first. This guide starts after the product and account decision.

The short answer

Use the 1Password SSH agent when you want Git and SSH clients to authenticate without reading the private key, and you are comfortable making the desktop app part of the local authentication path. Keep a conventional or hardware-backed alternative when unattended workloads, recovery, unsupported clients, or company policy require it.

The agent is a signer, not a key export shortcut

The 1Password SSH agent documentation says the private key does not leave the 1Password app. An eligible SSH client receives a signature after authorization; it does not receive the private key material.

Authorization lasts until 1Password locks under the configured approval model. That reduces repeated prompts, but it also means the unlocked-app window belongs in the threat model. Lock timing and device access still matter.

Public keys are not secret. They still need to be registered with Git hosts and remote servers, and their fingerprints should be recorded before migration.

Know what the agent makes eligible

1Password currently supports Ed25519 and RSA keys stored as active SSH Key items. By default, eligible keys in built-in Personal, Private, or Employee vaults are offered by the agent.

Keys in shared or custom vaults require an agent configuration file. Do not broaden the configured vault set merely because one connection failed; confirm the item type, vault, archive state, and public fingerprint first.

The SSH agent security explanation should be part of the review, especially when deciding which processes may request signatures and how approvals behave on the operating system.

OpenSSH servers commonly stop after several failed key offers. If the agent exposes more than six keys, match keys to hosts with SSH configuration or the current bookmarks feature instead of increasing guesswork.

1Password’s SSH Bookmarks documentation explains that generated bookmark configuration stores host URLs and public keys unencrypted on disk while private keys remain in 1Password. That is usually acceptable, but it is not the same as leaving no SSH metadata on disk.

Migrate one non-production key first

Do not import every key and delete the old files in one session. A staged migration proves the client, remote account, recovery path, and fingerprint mapping before the old credential is removed.

• Choose a low-risk repository or test host and record the current working key fingerprint.
• Generate a new Ed25519 SSH Key item in 1Password, or import the intended existing key only after checking its origin.
• Turn on 1Password Developer and the SSH agent in the desktop app.
• Point the shell or supported client at the 1Password agent using the platform-specific instructions.
• Add the new public key to the test destination while keeping the old key authorized temporarily.
• Test authentication, denial, app locking, device restart, and the intended recovery path.
• Remove the old authorized key only after the new path works from every required client.

Inspect the client before changing it

git --version
ssh -V
ssh-add -l

The agent list should contain the fingerprint you expect. A long list is a configuration signal, not proof that the desired key is being chosen.

ssh -G git@github.com | grep -E '^(hostname|user|identityfile|identityagent) '

The expanded SSH configuration helps reveal host aliases, identity files, and agent overrides. Do not paste private-key material or sensitive host inventories into a public issue while troubleshooting.

Authentication and commit signing are separate jobs

SSH authentication proves to GitHub, GitLab, Bitbucket, or another server that the connecting client controls an accepted key. Commit signing attaches a cryptographic signature to a commit or tag. A successful push does not prove the commit itself was signed.

Current 1Password Git signing documentation requires Git 2.34 or later for SSH signing and can configure the signing key and signer program from the desktop app.

The same SSH key can authenticate and sign, but separate keys can make purpose, rotation, and revocation easier to explain. The cost is more key inventory and a greater chance of offering the wrong key unless host and repository configuration are explicit.

Check the Git values that actually win

git config --show-origin --get gpg.format
git config --show-origin --get user.signingkey
git config --show-origin --get gpg.ssh.program
git config --show-origin --get commit.gpgsign
git config --show-origin --get user.email

The value and its origin both matter. A repository-local setting can override a correct global setup. A Git GUI may also use another Git binary or environment from the terminal.

Register the public key as a signing key on the relevant Git host. On GitHub, choose the Signing key type. GitLab and Bitbucket use their own usage labels. The commit author email must also match the account rules used for verification.

git commit --allow-empty -m "Test SSH signing"
git log -1 --show-signature

Verify locally and on the hosting service

Git hosting services can show a verified badge after the signing public key is registered. Local SSH-signature verification additionally needs an allowed signers file. A missing local file can prevent local verification even when the host verifies the pushed commit.

If a signed commit appears unverified, check the exact commit author email, registered signing key, repository-local overrides, and the Git client that created the commit before regenerating keys.

Not every client follows the same environment

Use the current SSH client compatibility table for terminal apps, Git clients, IDEs, containers, and remote environments. A client can ignore the shell’s agent socket or bundle an older Git version.

For a GUI client, confirm which Git executable it uses and whether it supports SSH signing. A terminal test cannot prove the GUI will sign or authenticate through the same path.

On Linux, 1Password states that Flatpak and Snap Store app installations do not support its SSH agent. Choose a supported installation method before debugging shell configuration.

Agent forwarding moves trust, not the private key

With agent forwarding, a remote environment can ask the local agent to sign while the private key remains local. The remote host may still request signatures during that session, so forwarding to an untrusted machine is not harmless.

Limit forwarding to named hosts, keep remote environments patched, and close sessions when the work is done. A cloud development environment also needs a recovery path when the local laptop or 1Password app is unavailable.

Do not use an interactive desktop agent as a server secret store

CI runners, production servers, and unattended jobs need non-interactive identities, narrow permissions, rotation, and audit ownership. A developer’s desktop SSH agent is the wrong dependency for most production automation.

For scripts that need application secrets rather than SSH signing, review 1Password CLI secret references and service accounts. Keep human SSH access and workload credentials as separate design decisions.

Plan recovery before removing old keys

• Keep a second tested account owner or recovery path where the account model supports it.
• Document which public fingerprint belongs to each Git host, server, and signing purpose.
• Know how to revoke a lost-device key from every remote destination.
• Keep emergency access instructions outside the password manager outage path.
• Test a locked app, offline laptop, and unavailable desktop integration before declaring the migration complete.

For teams, policy and ownership come before convenience

A shared company key weakens attribution. Prefer a key per person for human Git and SSH access, then control destinations with repository, server, and identity-provider permissions.

Offboarding should remove the person from 1Password and revoke their public keys or account access at every destination. Removing an item from one vault does not automatically prove that every server and Git host rejected the old key.

Business plan controls may govern developer features and app behavior. Confirm the quoted plan and policy settings instead of assuming every member can enable the same integration.

Swedish and EU teams still need a data and employment review

The account region affects 1Password billing and hosted account data, while the SSH agent performs local signing through the desktop app. Region selection does not replace a review of employer policy, administrator access, support, subprocessors, retention, and employee information.

SSH public keys and host mappings can identify systems and people even though they are not private credentials. Decide where that inventory is stored and who may inspect it.

A one-week pilot is enough to find most integration gaps

• Test terminal Git authentication and one direct SSH host.
• Test the actual IDE or Git GUI used for daily work.
• Sign a commit in a disposable repository and verify it locally and on the Git host.
• Lock 1Password and confirm the next request requires the expected authorization.
• Restart the laptop and test shell initialization rather than relying on the current session.
• Exercise revocation with a temporary key and confirm the old path fails.

Choose the agent when

• private keys should remain outside Git and SSH client processes
• developers already use the supported 1Password desktop app
• interactive authorization fits the workstation workflow
• host, client, remote-development, and recovery tests pass

Keep another approach when

• the workload is unattended or runs without a desktop session
• the required Git or SSH client is not compatible
• company policy requires a hardware-backed or centrally issued identity
• an outage or travel scenario needs an independent recovery credential

Evaluate the workflow before expanding the account

Run the pilot, then compare the team controls and rollout cost in the 1Password Teams vs Business guide.

If the workflow and plan still fit, check the current 1Password options. This direct tracked link currently earns no commission.

Primary sources checked

1Password SSH agent overview and eligible-key behavior

1Password SSH agent security

1Password Git commit signing with SSH

1Password SSH client compatibility

1Password SSH Bookmarks and generated configuration

1Password CLI secrets in scripts