SSH agent extensions as an arbitrary RPC mechanism | Hacker News Reader

SSH agent extensions as an arbitrary RPC mechanism

mjg59.dreamwidth.org

113 pointsJNRowe16 comments

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

AFAIR you can choose to use Windows OpenSSH or the other one during Git for Windows installation. [0]

[0]: https://duckduckgo.com/?q=git+for+Windows+openssh&t=fpas&iax...

Unfortunately it's difficult to enforce that, so dealing with users who've already set things up in a specific way is a problem

could always ship a static linked ssh_client

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.

The server can get the calling process info [0], which may be useful for local access control. TCP sockets cannot distinguish clients like that.

[0]: https://docs.rs/tokio/latest/tokio/net/struct.UnixStream.htm...

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.

Does the code for this exist somewhere?

It does, but unfortunately not somewhere I can point at it yet. I'm working on it.

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

Reply on news.ycombinator.com