SSH Agent Provider¶
The SSH agent provider derives a 32-byte secret by having the SSH agent sign a deterministic challenge. Only Ed25519 keys are supported.
Type: ssh-agent
Requirements¶
- A running SSH agent with at least one Ed25519 key loaded
- The
SSH_AUTH_SOCKenvironment variable must be set
How It Works¶
Enrollment¶
- Connects to the SSH agent via
SSH_AUTH_SOCK - Lists Ed25519 keys in the agent (auto-selects if only one)
- Generates a random 32-byte salt
- Builds a deterministic challenge:
SHA256(salt || fingerprint || "cryptkey-sshagent-challenge") - The agent signs the challenge with the selected key
- HKDF derives the secret:
HKDF-SHA256(signature, salt, "cryptkey-sshagent-provider") → 32 bytes - The key's SHA256 fingerprint and salt are stored in the profile
- The signature is wiped from memory
Derivation¶
- Connects to the SSH agent
- Finds the enrolled key by its stored fingerprint
- Rebuilds the same challenge from the stored salt and fingerprint
- The agent signs the challenge again — Ed25519 signatures are deterministic, so the same signature is produced
- The same HKDF derivation reproduces the 32-byte secret
Usage¶
# Interactive TUI
cryptkey init
# Select "ssh-agent" from the menu
# Non-interactive
cryptkey init --no-tui \
--add ssh-agent:yubikey \
--add passphrase:backup
# Derive — agent must have the key loaded
cryptkey derive
Stored Parameters¶
| Parameter | Description |
|---|---|
salt |
Hex-encoded 32-byte salt (used in challenge and HKDF) |
fingerprint |
SSH SHA256 fingerprint (e.g., SHA256:abc123...) |
No file path is stored — the key is identified by fingerprint in the agent.
Why Ed25519 Only¶
This provider relies on deterministic signatures: signing the same message with the same key must always produce the same signature. Ed25519 has this property by design.
ECDSA signatures include a random nonce, so different signatures are produced each time — the derived secret would change and key reconstruction would fail. While RFC 6979 defines deterministic ECDSA, not all SSH agent implementations guarantee this.
Security Notes¶
- The private key never leaves the agent — only the signature is used
- No key material is stored in the profile, only the fingerprint and HKDF salt
- The challenge is bound to the specific enrollment via the salt, so the signature cannot be replayed across profiles
- Works with hardware-backed keys (YubiKey, smart cards) where the key cannot be extracted
- The security depends on the agent and key storage — a YubiKey-backed key in the agent is stronger than a software key
When to Use¶
The SSH agent provider is ideal when:
- Your SSH key lives on a hardware token (YubiKey, smart card) and is only accessible through the agent
- You use an agent that manages keys for you (1Password SSH agent, Secretive on macOS)
- You don't want the private key file to be read directly
- You want a provider that works without any files on disk
SSH Agent vs SSH Key Provider¶
ssh-agent |
sshkey |
|
|---|---|---|
| Key access | Agent signs on behalf | Reads private key file directly |
| Key types | Ed25519 only | Ed25519, ECDSA, RSA |
| Hardware keys | Full support (YubiKey, etc.) | Only if key file is on disk |
| File on disk | Not needed | Required |
| How secret is derived | From agent's signature | From private key bytes |
| Agent required | Yes | No |