1Password SSH Agent for Crypto Projects: SSH Keys, Git Signing and CLI Secrets

The 1Password SSH Agent lets developers keep SSH private keys inside an encrypted 1Password vault and authorize supported SSH or Git operations without placing an unencrypted private-key file in the ordinary ~/.ssh workflow. For a cryptocurrency project, that can reduce exposure around source repositories, deployment servers, nodes and infrastructure accounts. It does not secure wallet keys automatically, replace server access controls or make every request legitimate.

Last reviewed: September 29, 2026. 1Password applications, plans, platform support, CLI syntax, SSH integrations and Git-hosting interfaces can change. Confirm current commands and compatibility in the official documentation. This independent guide is educational and is not affiliated with 1Password or a substitute for a professional security review.

What is the 1Password SSH Agent?

An SSH agent responds to cryptographic signing requests on behalf of SSH clients. A client can prove possession of a private key without the private key being transmitted to the remote server. The server stores the corresponding public key and verifies the response.

1Password includes an SSH agent that makes eligible keys stored in a vault available to supported local tools. When an application such as ssh or git requests a signature, 1Password can identify the key and ask the user to approve its use. On supported devices, that approval can use biometric or system authentication.

This is different from copying a private key out of the vault and saving it as an ordinary file. The goal is to use the key while keeping its routine storage and authorization inside the 1Password workflow.

Why this matters for a crypto project

Crypto projects combine conventional infrastructure security with high-value irreversible systems. A compromised development credential might let an attacker alter a website, replace a wallet download, inject a malicious dependency, reach a node, change a deployment pipeline or obtain a trading bot’s secrets.

Typical sensitive credentials include:

• SSH keys for servers, validators, monitoring systems and cloud hosts;
• GitHub, GitLab or Bitbucket access credentials;
• Git signing keys used to establish commit provenance;
• exchange API keys used by reporting or trading software;
• RPC provider tokens and blockchain explorer API keys;
• CI/CD deployment tokens;
• database passwords and webhook secrets;
• cloud-provider and infrastructure-as-code credentials.

Centralizing every secret in one product also creates concentration risk. Use separate vaults, minimal permissions, strong device security, tested recovery and independent controls at the service or server.

SSH keys, API keys and wallet keys are not interchangeable

The phrase “private key” describes several cryptographic contexts. Importing an SSH key into an SSH-agent workflow does not imply that the same method is appropriate for a seed phrase or a wallet signing key. Follow the wallet manufacturer’s recovery guidance and threat model for long-term crypto assets. Never paste a seed phrase into a shell command, Git repository, environment variable or developer automation.

1Password SSH Agent versus a conventional local agent

The 1Password design can reduce loose private-key files and add approval friction. It does not replace server-side logging, intrusion detection or public-key revocation. If an unlocked trusted device is compromised, malicious local software may still attempt to request signatures or steal other accessible data.

Prerequisites

Before changing a working SSH setup:

• install a current official 1Password desktop application;
• confirm the operating system and local SSH client are supported;
• protect the 1Password account with its current recommended authentication model;
• enable full-device encryption and a strong screen lock;
• retain a tested recovery method for the 1Password account;
• keep a working administrative recovery path to important servers;
• record which services currently trust each public key;
• do not delete the old key until the new path has been tested.

Make the first change on a noncritical repository or test server. A configuration error can lock out legitimate administrators even when no secret has been exposed.

How to enable the Developer experience

In a current supported desktop app, open 1Password settings and locate the Developer section. Enable the developer experience and the SSH Agent option. Interface wording and socket locations differ among macOS, Linux and Windows, so use the platform-specific instructions shown by the application.

Do not install an unofficial browser extension, package or shell script claiming to “activate” the agent. Download 1Password through an official distribution channel and compare commands with current documentation before running them.

Create a dedicated SSH key

A key can be generated as an SSH Key item in 1Password. Use a descriptive item name that states purpose and environment, for example:

• GitHub – personal signing – 2026;
• GitLab – project access – development;
• Node 03 – production SSH – operator;
• Deployment – staging – CI read only.

Avoid a vague collection of items named “SSH key.” Clear ownership and purpose make revocation possible during an incident.

Ed25519 is a common modern choice where all target systems support it. RSA can remain necessary for compatibility, but key size and server policy matter. Do not choose DSA or another obsolete algorithm merely because an old tutorial uses it. The target service’s current requirements are authoritative.

Import an existing SSH key carefully

Importing can reduce the number of loose key files, but it does not erase copies automatically. First identify every copy, backup and system that trusts the corresponding public key. Confirm that the key has an appropriate algorithm, strength, owner and purpose.

1. Open the official 1Password application.
2. Create or choose the intended vault with appropriate access membership.
3. Use the supported SSH-key import process.
4. Verify the displayed public-key fingerprint.
5. Test the imported key through the agent.
6. Back up access through a separate administrator or recovery key.
7. Remove obsolete plaintext copies only after testing and according to the organization’s retention policy.

Deleting a file normally does not prove that old storage media, backups or shell history contain no copy. If the key may have been exposed, rotate it instead of treating file deletion as remediation.

Add only the public key to the destination

A remote server or Git provider needs the public key, not the private key. 1Password can expose the public component for copying or supported autofill. Verify the destination account, item label and fingerprint before saving.

Never paste the private-key block into GitHub, GitLab, a hosting control panel or a support chat. A form labelled “SSH key” usually expects the line beginning with a public algorithm identifier, but the platform documentation should confirm the exact format.

Configure the SSH client

The local SSH client must know how to communicate with the 1Password agent. The required configuration varies by operating system. 1Password publishes platform-specific socket or named-pipe instructions and can provide configuration guidance inside the Developer settings.

A typical SSH host configuration can also restrict which key is offered to a destination. This is useful when one user manages several Git identities or environments. Keep host aliases explicit and avoid wildcard rules that offer every key to every server.

Test authentication without risking production access

After adding the public key, test against the service’s official SSH verification method or a noncritical host. Confirm:

• the expected 1Password item appears in the approval prompt;
• the destination hostname is correct;
• the selected user and key fingerprint match the plan;
• authentication succeeds without exporting the private key;
• the event appears in the appropriate local and remote logs;
• the previous recovery route still works.

Do not remove the old public key from a remote server while the only active terminal is using it. Open a second session and verify the new credential first.

Approval prompts and biometric authorization

On supported systems, 1Password can ask for biometric or system authentication before authorizing key use. This creates an opportunity to reject an unexpected request, but only if the user reads the prompt.

Check the key name, requesting application and context. Repeated unexplained prompts can indicate a background development tool, an incorrectly configured Git client or malicious software. Reject first and investigate rather than approving until the prompt disappears.

Biometrics approve use from the device; they do not prove the remote server is trustworthy. SSH host-key verification remains necessary to detect an unexpected server identity.

SSH host keys and user keys solve different problems

The user’s SSH key proves identity to the server. The server’s host key lets the client verify which server it reached. Storing a user private key safely does not protect against accepting a fraudulent server fingerprint.

Investigate warnings that a host identification changed. A legitimate server rebuild can change the fingerprint, but so can interception or DNS manipulation. Verify the new fingerprint through a trusted administrative channel before updating known_hosts.

Use separate keys for separate roles

One universal key creates a large blast radius. If it is revoked, every system breaks; if it is abused, every trusting system is exposed. Divide keys according to risk and operational ownership.

Sign Git commits with 1Password

Git signing attaches a cryptographic signature to a commit or tag. A hosting service can compare that signature with a public key registered to an account and display a verified status when its requirements are met.

1Password can store an SSH signing key and help configure Git to call the supported signing program. After configuring the correct key and user identity, create a harmless test commit and verify it locally and on the hosting service.

Configuration commonly needs to identify SSH as the signing format, select the intended public key and enable signing for commits or tags. Do not copy commands from an unrelated account: Git email, repository policy, operating system and hosting provider must all align.

What a Verified commit proves—and what it does not

A valid signature establishes that the holder of a particular private key signed the commit data. A hosting provider’s Verified badge additionally reflects its association and verification rules.

It does not prove that:

• the code is safe or free of malicious logic;
• the signer reviewed every changed line;
• the developer’s device was uncompromised;
• the dependency tree is trustworthy;
• the deployed binary was built from that exact commit;
• the private key has never been misused.

Commit signing is strongest when a repository protects branches, requires review, verifies signatures, scans dependencies and produces reproducible or attestable builds.

Why crypto repositories benefit from signed commits

Wallet software, smart contracts and deployment tooling can affect valuable assets. Signed commits make unauthorized attribution harder and provide another signal during review. Protected release tags can also help connect published source history with an approved release process.

A signature cannot prevent a maintainer from approving dangerous code or an attacker from using an already-unlocked signing path. Teams still need independent review, branch protection, CI isolation and release-key controls.

Review the SSH Agent activity log

The 1Password Developer experience includes a locally stored activity log for recent SSH-agent requests. According to 1Password, it can show the key and application involved, the command and whether a request came from a background process.

Use the log to investigate:

• a prompt that appeared without an intentional command;
• a key offered to the wrong repository;
• an IDE repeatedly checking remote status;
• a script initiating unexpected SSH connections;
• a signing key used outside the expected Git workflow.

A local log is helpful but not an immutable security audit. Correlate it with Git-provider, server, cloud and identity logs.

Developer Watchtower and SSH key health

Developer Watchtower can identify potential security issues involving developer credentials. 1Password has described checks for SSH keys found on disk, including old algorithms, weak RSA sizes, missing encryption and keys that may be better imported into the vault.

A warning is a starting point. Before changing a key, map its dependencies and create a replacement plan. Deleting an old key file before updating every required server can cause an outage without improving security.

What is 1Password CLI?

The 1Password command-line interface, commonly invoked as op, lets supported scripts and terminal workflows retrieve or reference vault items after authorized sign-in. Its value is not merely copying a password into the terminal. Safer patterns keep the secret out of source code and expose it only to the process that needs it.

CLI access should use a purpose-built vault, narrow item permissions and the most suitable identity model for the environment. An interactive developer session and an unattended production service have different requirements; do not use a personal desktop session as a permanent server secret manager.

Secret references instead of plaintext values

A 1Password secret reference identifies a vault item and field without embedding the secret’s actual value in a configuration template. Supported CLI operations can resolve the reference during execution.

This can reduce exposure in:

• Git repositories;
• shared configuration examples;
• developer documentation;
• shell scripts;
• local environment templates.

A reference can still reveal the vault or item naming scheme, and anyone authorized to resolve it may obtain the underlying value. Protect permissions and avoid descriptive names that unnecessarily disclose production architecture.

Runtime injection with the CLI

Supported op run and op inject workflows can provide secrets to a process or render a configuration from secret references. Use the official syntax for the installed CLI version.

Runtime injection reduces persistent plaintext, but it does not make the receiving process safe. A secret can leak through:

• debug logging;
• error messages;
• process inspection;
• crash dumps;
• child processes;
• application telemetry;
• malicious dependencies;
• screenshots or copied terminal output.

Configure the application never to print authentication values and limit access to logs.

Protect exchange API keys

A trading or reporting application may require an exchange API key, secret and sometimes an additional passphrase. Store each component as a protected field and inject it only into the intended application.

Security begins at the exchange:

1. Create a separate API key for one application and environment.
2. Grant read-only access when trading is unnecessary.
3. Disable withdrawals unless the documented design absolutely requires them.
4. Apply an IP allowlist where supported and operationally suitable.
5. Set subaccount and symbol restrictions if available.
6. Record an owner, creation date and rotation date.
7. Monitor API activity and failed requests.
8. Revoke the key immediately when its purpose ends.

1Password protects storage and access; it cannot make an overprivileged exchange token safe.

Never commit a secret to Git

A secret placed in a commit can remain in repository history, forks, pull-request diffs, CI logs and developer clones after the visible file is edited. Adding the filename to .gitignore afterward does not undo the exposure.

If a secret is committed:

1. Revoke or rotate it immediately.
2. Determine which permissions and systems it exposed.
3. Review provider logs for misuse.
4. Replace it in every legitimate deployment.
5. Remove it from history when appropriate, coordinating with collaborators.
6. Invalidate cached artifacts and CI outputs.
7. Add automated secret scanning and a prevention control.

History rewriting is cleanup, not credential recovery. The old secret must be considered compromised.

Vault design for development, staging and production

Do not place every developer credential in a vault shared with the entire team. Create boundaries based on environment, role and operational need.

Vault separation is useful only if membership is maintained. Review access after role changes and remove unnecessary users promptly.

Do not share one private SSH key with the team

When several people use the same key, server logs cannot reliably identify the individual. Removing one person’s access requires replacing the shared credential for everyone, and copies can persist on old devices.

Give each human a named identity and public key. Use group authorization on the server or identity layer. For automation, create a dedicated machine identity with narrowly scoped access, a responsible owner and a rotation process.

Offboarding and access revocation

Removing someone from a 1Password vault is only one step. A complete offboarding process should:

• remove the user’s public keys from servers;
• remove Git-organization and cloud access;
• revoke personal access tokens and active sessions;
• rotate shared secrets the person could reveal;
• review recent SSH, Git, API and administrative logs;
• transfer ownership of automation and recovery procedures;
• remove trusted devices and identity-provider access.

An encrypted vault cannot retract a secret a person previously copied or viewed. Rotate high-impact shared credentials after access changes.

Key rotation

Rotation replaces a credential and removes trust in the old one. Use it after suspected exposure, an employee departure, a device compromise, a policy deadline or a cryptographic recommendation change.

1. Create a new key with a distinct name and date.
2. Add the new public key to each approved destination.
3. Test authentication and recovery.
4. Update documentation and ownership.
5. Remove the old public key from every destination.
6. Archive only information required by policy; do not leave an active duplicate.
7. Review logs around the rotation window.

Keep an inventory so a forgotten host does not continue trusting the old key indefinitely.

Lost or compromised device

If a device containing an authorized 1Password app is lost, use a separate trusted device and official account controls. Remove the lost device where supported, secure the associated operating-system and identity accounts, and evaluate every key or token the device could use.

Rotate high-impact SSH keys, API tokens and signing keys when unauthorized use is plausible. Review Git signatures, repository actions, server logins, cloud events and exchange API activity. Do not wait for visible asset theft before revoking access.

Malware and local process risk

An SSH agent keeps the private key out of ordinary files, but malware running under the user’s account may still trigger requests, tamper with commands, read injected secrets or act after authentication. Explicit approval helps only when the prompt is correctly interpreted.

Reduce local risk by using current software, limiting extensions and packages, separating administrative work, reviewing dependency installation scripts and avoiding development on an already compromised device. High-value production actions may justify a dedicated workstation or stronger hardware-backed controls.

Backup and recovery planning

Before relying on 1Password for critical SSH access, test how the account and vault will be recovered after loss of the primary device. Protect the Emergency Kit or current equivalent separately and never store it unprotected beside the only device it is meant to recover.

Server recovery should not depend on one password-manager account. Maintain a controlled break-glass path, a second administrator or provider console procedure. Document use and monitor it closely so recovery access does not become a permanent bypass.

Troubleshooting: the agent is not available

Check that the official desktop application is running, unlocked and updated; the SSH Agent option is enabled; and the local client points to the platform’s current agent socket or pipe. Restart the relevant application after a configuration change.

Inspect environment variables and competing agents. A shell, IDE and graphical Git client can inherit different environments. Confirm which SSH executable each tool uses instead of assuming they share one configuration.

Troubleshooting: the wrong key is offered

Give items clear names, restrict eligible vaults where supported and configure host-specific identity rules. Review whether several public keys are registered to the same provider account.

Do not approve multiple prompts at random. Compare the fingerprint with the public key registered at the destination and remove obsolete keys from both the provider and local workflow.

Troubleshooting: Git commit is not Verified

Confirm that the commit contains a signature, Git is configured for the intended SSH signing key and the corresponding public signing key is registered with the hosting account. The commit email or identity may also need to satisfy provider rules.

Local signature validity and a platform badge are related but different checks. Inspect the commit with Git’s signature display, then consult the hosting provider’s current verification requirements.

Troubleshooting: server rejects the key

Compare the public-key fingerprint, remote username and target host. Check server authorization files, file permissions, SSH policy and logs. The remote server may reject an algorithm or key type even when the 1Password approval succeeds.

A successful local signing prompt proves only that the agent used a key. It does not prove that the destination trusts the corresponding public key.

Troubleshooting: CLI secret is empty or unavailable

Verify that the current CLI session is authenticated, the account and vault are correct, the item and field reference exist and the identity has permission. Check quoting and template syntax without printing the actual secret.

Do not enable unrestricted shell tracing to diagnose a production secret. Debug with a harmless test value or isolated development vault, and sanitize logs afterward.

Security checklist for a crypto developer

• Install 1Password only from an official source.
• Protect the account and every authorized device.
• Use modern, purpose-specific SSH keys.
• Separate authentication and Git signing keys.
• Register only public keys with remote services.
• Read every SSH Agent approval prompt.
• Verify remote SSH host fingerprints.
• Use named individual access instead of a shared private key.
• Separate development, staging and production vaults.
• Keep API permissions minimal and disable withdrawals by default.
• Use secret references and runtime injection instead of committed values.
• Prevent applications from logging secrets.
• Review SSH Agent, server, Git and provider logs.
• Maintain an inventory and scheduled rotation process.
• Test account and server recovery before an emergency.
• Keep seed phrases out of developer tooling and source control.

Frequently asked questions

Does 1Password store SSH private keys?

It can store supported SSH key items in encrypted vaults and make eligible keys available through its built-in SSH Agent. Access still depends on the account, device, application and configured authorization rules.

Does the private key get sent to the SSH server?

No. SSH public-key authentication uses a signature created with the private key. The server verifies it with the registered public key. The private key should not be uploaded to the server as part of ordinary authentication.

Can 1Password SSH Agent work with GitHub or GitLab?

Yes, when the local Git/SSH configuration and provider account are set up with the corresponding public key. Follow the current instructions for the operating system and hosting provider.

Can 1Password sign Git commits?

Yes. A supported SSH key stored in 1Password can be configured for Git signing. The corresponding public signing key must also meet the Git hosting provider’s verification requirements.

Is a Verified commit guaranteed to be safe?

No. It verifies a cryptographic relationship and provider identity rules, not code quality. Review, testing, protected branches and secure builds remain necessary.

Should an SSH authentication key and Git signing key be the same?

Separating them usually creates clearer purpose and easier revocation. A compromised authentication path can then be replaced without also changing the signing identity.

Can I keep exchange API keys in 1Password?

1Password can protect their storage and support controlled retrieval. The exchange key must still use minimal permissions, IP restrictions where appropriate, monitoring and regular rotation.

Should a seed phrase be stored with developer secrets?

This guide does not recommend placing seed phrases in source-control, shell, environment-variable or SSH workflows. Use the wallet provider’s recovery guidance and an offline backup plan suited to the asset and threat model.

Does 1Password CLI prevent secrets from leaking?

It can avoid persistent plaintext and committed values, but the receiving process, logs, child processes or malware can still expose a resolved secret. Design the complete runtime safely.

What should I do if an SSH key may be compromised?

Remove its public key from every destination, create a replacement, review logs and investigate the affected device. Merely deleting the local private-key item does not revoke remote trust.

Why does 1Password keep asking to approve SSH activity?

An IDE, Git client, terminal or background process may be making requests. Reject unexplained prompts and inspect the SSH Agent activity log before changing approval settings.

Final perspective

The 1Password SSH Agent can improve a crypto development workflow by reducing loose private-key files, making SSH use visible and adding approval to supported operations. Git signing adds provenance, while the CLI can keep API tokens and deployment secrets out of source code.

These tools do not replace least privilege, device security, remote logging, secret rotation or wallet-specific key management. Build around clear identities: one key per purpose, one responsible owner, narrow access and a tested way to revoke it.

Official sources and further reading

• 1Password Developer — SSH Agent documentation
• 1Password Developer — Git commit signing
• 1Password Developer — Command-line tool
• 1Password — Developer experience and SSH activity log
• 1Password — Watchtower SSH key checks