16 comments

[ 5.2 ms ] story [ 29.6 ms ] thread
Does the code for this exist somewhere?
Doesn't look like it, but the author uses the Go SSH agent library [1] which _does_ have some example code there and looks pretty straightforward, based on what was described in the post.

[1] https://pkg.go.dev/golang.org/x/crypto/ssh/agent

It is indeed very straightforward. I did a quick check and I use this exact library for my "coarse-grained Debian diff" program, `meikkalainen` [1], and I was able to get it up and working mostly how I wanted within the same morning I started it. Very straightforward, even for a guy who doesn't spend a lot of time in the Goverse.

[1]: https://github.com/hiAndrewQuinn/meikkalainen/tree/main

It does, but unfortunately not somewhere I can point at it yet. I'm working on it.
SSH agent extensions are really powerful.

I'm maintaining a crate for writing own agents (and clients) and just recently added an example of providing decryption over extensions [0] which, coupled with the other examples, allows using SSH agent as a proxy between OpenPGP Card devices (eg Yubikeys) and OpenPGP encrypted data.

[0]: https://github.com/wiktor-k/ssh-agent-lib/pull/70

Got some really positive feedback about this one: https://chaos.social/@Foxboron/112416348981479022 ;)

> Windows didn't really do Unix sockets until recently so everything there is awful

Sadly the support for Unix sockets on Windows in Rust's standard lib is stuck in a limbo: https://github.com/rust-lang/libs-team/issues/271

Fortunately the built-in Windows' SSH client and agent work over Named Pipes and it's quite easy to communicate with them that way: https://github.com/wiktor-k/ssh-agent-lib#agent

Unfortunately the version included in git for Windows doesn't and you have to emulate sockets using magic files instead...
What is so great about Unix sockets that e.g. a normal TCP socket bound to localhost or even a named pipe can not do properly?
UNIX Sockets are more flexible than named pipes;

* You can use them for more than two processes communicating (eg. a server process with potentially multiple client processes connecting);

* They are bidirectional;

* They support passing kernel-verified UID / GID credentials between processes;

* They support passing file descriptors between processes;

* They support packet and sequenced packet modes.

TCP only grants you 2 of these extra features (sequenced packet mode/bidirection), leaving a giant hole in security in the process.

The named pipes, at least on Windows, also support all of that except for passing UID/GID and file handles.
How hard would that be to extend that to include PKCS#11?
The SSH agent shipped with OpenSSH already includes PKCS#11 support (check out the `-s` flag). I'm using that daily to work with TPM-backed keys.
I've done the same with https://github.com/42wim/ssh-agentx/ Originally used to sign git commits with pgp in the sshagent, before ssh git commit signing was a thing.

Nowadays, I'm using it for signing code remotely on a server with a yubikey on the local laptop. (needs a patched relic - https://github.com/42wim/relic/tree/sshtoken)

Also works with windows as it uses https://github.com/buptczq/WinCryptSSHAgent that did the hard work to get it to talk with almost everything that exists in windows/wsl/putty etc.