ssh-agent support

[42wim]

I've made a POC for ssh agent support by creating a ssh-agent which uses the ssh-agent extension mechanism. (this way we can keep our keys secure on our devices)

Is this something you would want to support (I can make a PR) or is this out of scope?

[FiloSottile]

Oh this is interesting. It's definitely too soon because age is not even stable yet, but I want to think about this when thinking about the agent strategy. I didn't know the ssh-agent protocol was so extensible. If it's a sane protocol we might even adopt it as the one age agent protocol. Might as well.

[FiloSottile]

Relevant post on the mailing list: https://groups.google.com/d/msg/age-dev/Xe6zW4haGx8/m_jYh7YTAgAJ

[charles-dyfis-net]

ssh-agent support would also make it unnecessary to use something like go-piv to use private keys stored on dedicated hardware that GnuPG already supports.

[ygrek]

Is there any plan to look at this before 1.0 release?

[T4cC0re]

This would also be helpful in the case someone encrypts a message to a GitHub user's SSH key.

In my case I use a smart card with GPG for my SSH keys, so this ssh-agent support would make this usable in the first-place for my use-case.

Also this means we can update the and that SSH keys held on YubiKeys can't be used to decrypt files. note in the readme 🙂

[FiloSottile]

Note that since this is a non-standard ssh-agent extension, gpg-agent does not support it, so this does not unlock the capability of using keys on YubiKeys through it.

This is a very interesting experiment, but I think we'll focus on native support for YubiKeys (both PIV and maybe even FIDO2 in symmetric mode) and on a dedicated agent (probably https://github.com/FiloSottile/yubikey-agent) which lets us support native age keys.

[frainz-de]

I'm also interested in this feature. I keep my SSH keys in a keepassxc database, so I currently cannot use them with age.

[mortenbirkelund]

@FiloSottile Now that Age is released in a stable version, are there any thoughts about making it possible to decrypt using ssh files on your yubikey?

[nnWhisperer]

is this feature corrently supported?

[nikolaishields]

Any updates or new thoughts regarding agent support?

[mspreij]

I don't know anything about Go and too little about SSH/encryption, but this guy https://github.com/leighmcculloch/sshcrypt has a working solution that does this - which links to this repo :-D Maybe you can exchange some code? I'm using his version and it's pretty damn nice to not have to worry about db credentials and such hanging out in scripts in plaintext.

[covert-encryption]

I don't quite get his explanation. So, sign some random bytes (via agent) and use the signature as an encryption key. I assume that should be used for decryption. But how can you derive that same key at the sending end, who only has the public key of the recipient and thus cannot produce a signature? Or is this just a fancy way to do symmetric encryption using one's secret key for both encryption and decryption?

[covert-encryption]

FWIW, Covert Encryption would need ECDH ideally also XEdDSA signatures on a hardware tokens, using Curve25519 keys (Age keys) for both. Ledger Nano and compatible USB keys should be able to do that with a custom program. Yubikey probably never could do the signatures, but barring that (as an optional feature), its Curve25519 keypairs should be usable with ECDH and therefore all other functions needed.

[mspreij]

The way I'm using it is for local en/de-cryption only, in the simplest way: https://github.com/leighmcculloch/sshcrypt#usage
So while my ssh-agent is running and making my ssh keys available, I can run scripts that require passwords without having those passwords in plaintext anywhere (being read in with $(cat ~/keys/dbaccess.crp | sshcrypt agent-decrypt) ), and without having to enter any passwords to decrypt them (ssh-agent deals with that).

As for your second reply, I'm sorry, I do not know enough about it to understand it :-)

[covert-encryption]

Okay, so basically abusing ssh-agent to get symmetric keys. I guess that can be useful :-)

As for the other message, just saying that Yubikey probably can't sign and encrypt with the same key, while Ledger probably could do that (because you can write your own programs for it, supporting more protocols than what Yubikey has built in).

[iainsproat]

As 1password now provides an ssh-agent, I'd love to see support for ssh-agent in age.

[pinpox]

As 1password now provides an ssh-agent, I'd love to see support for ssh-agent in age.

Bitwarden/vaultwarden now also does. Would be nice to use the keys in the password manager with age.

[cpainchaud]

I can only add my name to this one. I have 3 tokens of different vendors and all exposed via Putty CAC via OpenSC. I currently do ugly scripting to mount my encrypted partitions and files with the decryption of my passphrase via pkcs11-tool. I am craving to get something usable directly like this project!!

[rbuzatu90]

Also interested in this one ! Any updates ?

[ebi-droid]

ssh-agent for age: https://github.com/IxDay/janus

[cipriancraciun]

Could you provide more information on how this works? (The readme doesn't say much.)

[voltagex]

I just ran into another situation where this would be useful - headless Linux boxes still don't have secure Git credential storage by default, I could wire something up with age but I'd like to be able to use my SSH keys in my agent to unlock it.

[voltagex]

@42wim why do you need to extend the agent for this to work? If age works with standard keys, wouldn't it also work with standard SSH keys from an agent?

[wiktor-k]

I think this is due to cryptographic primitives: SSH agent exposes only one for signing. If the raw cryptographic material is available age can transform and manipulate it in a way that's not possible through the constrained set of ops available through the agent.

It would be good to have a documented protocol on what's necessary. Since SSH agent protocol supports extensions it's possible to write a custom one which would support age decryption. (And maybe even add that support to native OpenSSH agent).

[cipriancraciun]

I've tried to give an answer to this question on this other thread:
=> #532 (comment)

[voltagex]

So before I realised this, I wrote a decrypt-only hack to get keys from agents voltagex-forks@d6b81ae - this is bad code and will break stdout output. Sorry about what I did to your code, Filippo!

To use an Australian phrase, this is "rough as guts".

I still think it'd be useful to be able to decrypt using identities from an agent, even if encryption wasn't possible.

[dehnert]

Encryption should be doable with just the public key, right? If that's the case, decryption with a stock agent and encryption using public keys would be perfectly fine and everything I want.

... but from the change, I think you meant to say your commit is for encryption-only?

[dbohdan]

I have just published a proof-of-concept agent for age. This one is written in Bash with password managers like passage in mind: dbohdan/stone-agent. It comes from the realization you only need a shell and netcat or socat to listen and respond on a Unix domain socket like "real" agents.

[dbohdan]

I am now working on a password manager with a similar agent design, pago. It is forked from pash, written in Go, and partially compatible with passage password stores.

[dbohdan]

I have factored an age decryption agent out of pago. pago-agent is now its own Go package and executable. It speaks RESP (the Redis protocol) on a Unix domain socket. This means you can access it with a Redis/Valkey client in a bunch of programming languages as well as with redis-cli or valkey-cli for manual debugging. The agent understands the commands IDENTITIES age-identities (parse and remember identities) and DECRYPT data (decrypt with the remembered identities), plus PING and SHUTDOWN.

The password manager itself has matured enough that I have replaced my use of GPG-based pass with it and declared it beta.

[bb-Ricardo]

As SOPS now added support for SSH Keys in age encryption it would be great to get SSH Agent support for age which then could be added to SOPS. This would solve A LOT of security concerns about having to expose private keys on remote machines.

[c33s]

i also use age with ssh-keys in sops and now get prompted all the time for the password to decrypt my ssh key even if i loaded the key with ssh-agent. please add support for ssh-keys already loaded in ssh-agent

[musjj]

Yeah, having this issue too. I'm using sops to decrypt secrets automatically after log in (gnome-keyring-daemon automatically unlocks on log in), and this limitation is forcing me to keep my SSH keys unencrypted. Really hoping that there will be a solution here. This is something that was possible with gnupg, so it'd really unfortunate if age can't fill in this use-case.

[k4lizen]

ditto

[na4ma4]

I think the issue a lot of people are missing is that the SSH agent never exposes the private key by design, I'll add my voice to the others saying the same thing.

It only proves it has the private key to something else, so when you connect to a remote server the server basically says "prove you have the private key by signing this string 'blahblah". and the agent signs it using the private key and returns it, thus proving it has the private key.

if the agent exposed the private key that'd be super insecure for agent forwarding, a nefarious actor could script stripping the private keys out of an agent when a person logs into a server.

[lukx]

that sounds super interesting, and I would love to understand this: In my assumption (edit: incorrect, see below:), ssh can decrypt the messages/connections that the remote machine encrypted for my public key. This is done through some dragon magic involving, probably, ssh-agent + Keychain on my Mac, and similar mechanisms on Linux.

If that understanding is correct (which I do not know) - then in what detail is the use case in age (or in sops, because that's where my use cases come from) different?

I found this link just now after sending my comment, which seems to look at this precise question. So, as @na4ma4 correctly summarized:
My initial assumption is incorrect, in SSH the asymmetric keys are not used for traffic decryption; just for the handshake by proving the possession of a private key through signing a message. So indeed, ssh-agent can't decrypt our sops secrets for us by design. Thank you for filling my knowledge gap @na4ma4 .

[cipriancraciun]

@lukx technically in the case of RSA (which Age doesn't support), at the lowest cryptographic level, there is no difference between decryption and signing, as they use exactly the same cryptographic primitive. (Obviously well behaved software wouldn't allow anyone to just sign random data, as given this is actually decryption, one could be tricked to decrypt through signing.)

Thus, if age were to support RSA keys, then one could theoretically use ssh-agent to decrypt.

---

However, if you are interested in using ssh-agent for encrypting to yourserf (i.e. using it as one would use a secret password), I've written more about this in the following comment: #532 (comment)

[CertainLach]

Slightly irrelevant for pure ssh-agent users, but is useful for those who use gpg-agent for ssh

I have implemented a plugin that only uses gpg-agent for encryption and decryption tasks: https://github.com/CertainLach/age-plugin-gpg/

It is however does not abuse the standards, and uses the encryption, and not the authentication keygrip that is used by ssh-agent.

It is not perfect, and is not tested much, but I am successfully using it for some time.

[kinthaiofficial]

ssh-agent support for age would be a significant workflow improvement — for users who already manage SSH keys via agent, adding age keys to a separate system creates friction.

Current state: age supports SSH keys (age -r ssh-rsa AAAA... or ~/.ssh/id_ed25519.pub), but doesn't use the agent — it reads private keys directly from disk.

What ssh-agent support would enable:

# Ideal: decrypt without touching key files
age -d -o plaintext.txt --agent encrypted.age
# age queries ssh-agent for the private key, no disk access needed

The security tradeoff:

• Current: private key on disk, agent not involved. Requires key file to be available.
• With agent: agent holds decryption key in memory. Works on systems where key is agent-forwarded but not on disk.

Implementation approach (RFC 4252 extension):
SSH agents expose an SSH_AGENT_SIGN operation. For decryption, you'd need either:

1. A custom age plugin that speaks to the agent via SIGN + key extraction (not clean)
2. SSH agent protocol extension for ECDH operation (cleaner but requires agent support)
3. PKCS#11 / hardware key integration (hardware wallets, YubiKey via PKCS11 already works)

The age-plugin-yubikey and age-plugin-tpm approaches show the plugin model works. An age-plugin-ssh-agent would follow the same pattern.

Is there appetite for implementing this as a plugin vs. core feature? The plugin route avoids adding ssh-agent dependency to age core.

[eszio]

For anyone still landing here: I built age-plugin-sshagent — a standard age plugin (identity-v1) that gets decryption working with a stock ssh-agent, within the constraint discussed above that the agent can only sign.

How it works: at keygen the agent signs a fixed, domain-separated challenge; the deterministic (RFC 8032) Ed25519 signature seeds HKDF, yielding a native X25519 age identity. Decryption just re-derives it from the agent on demand.

Properties:

• Recipients are plain age1... — the encrypting side uses stock age, no plugin needed
• The identity file contains no secret material (key fingerprint + salt only), safe to commit anywhere
• Works with passphrase-protected keys: the agent holds the unlocked key. My actual use case is age decryption inside hooks with no TTY to prompt on.

Honest caveats, since this is the signature-derived-key approach Filippo has (rightly) declined to put upstream: ssh-ed25519 only (sk-*/RSA signatures aren't deterministic), and anyone who can ask your agent for a signature — including remote hosts via agent forwarding — can derive the decryption key. The README documents the full security model.

https://github.com/eszio/age-plugin-sshagent

[frantathefranta]

*Claude built