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?

[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.

[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.