keyroost ssh (and other) agent?

[plaflamme]

I'm interested in keyroost as a replacement for piv-agent and gpg-agent, in part because:

1. it is cross-platform (I need linux + macos)
2. it is written in rust (personal preference)
3. already supports applets I need (PIV and OpenPGP)

My personal requirements:

1. support ssh-agent identities backed by PIV and OpenPGP
2. support pinentry protocol and pin-caching
3. (longer term) support age identities (i.e: age-plugin-keyroost)

Other potential features:

4. support gpg-agent protocol (seems hard / low value, but could help users with legacy use-cases)

Current State

I've started working on this and have a working (but simple and incomplete, no tests) PIV-backed ssh-agent here. You can try it like this (requires a pinentry of some kind):

cargo run -p keyroostctl -- agent --socket-path keyroost.sock
# in another terminal
SSH_AUTH_SOCK=./keyroost.sock ssh-add -l

and the output should be something like

256 SHA256:Rw...sk PIV Authentication (ECDSA)
256 SHA256:fs...6g PIV CardAuthentication (ECDSA)
256 SHA256:AO...qQ PIV Retired(1) (ECDSA)

SSH_AUTH_SOCK=./keyroost.sock ssh ... should also work.

My questions are:

1. is there interest in having this in keyroost itself?
2. are these high-level requirements reasonable?
3. what would it take to get a first version merged?
4. should this be part of keyroostctl, e.g.: keyroostctl agent --socket-path keyroost.sock ... or some other binary, e.g.: keyroost-agent?

A rough sketch of the cli might be something like this:

keyroostctl agent \
  --socket-path foo.socket \ # specify the socket to bind to
  --piv \ # enable/disable PIV-backed identities
  --piv-slots 9a,9c,r1-4 \ # manually select piv slots to use
  --pgp \ # enable/disable OpenPGP-backed identities
  --pgp-option \ # pgp-related options
  --pinentry \ # select the pinentry binary
  --pin-cache-duration 15s \ # pin-caching related options

I haven't explored what an age-plugin would require.

[plaflamme]

@framefilter fyi

[framefilter]

@plaflamme great proposal and apologies for the lack of response, life gets in the way sometimes. It's a thoughtful proposal, and a working prototype makes it much more concrete. Short answers first, then the part where I'd like everyone's input.

1. Is there interest? Yes. Using keys, not only managing them, is where I'd like keyroost's world to go eventually (see also #74). But keyroost's management features come first; they still need to mature across more hardware. So an agent would take a back seat for now. It might even be better as a sibling project built on keyroost's crates than as part of keyroost itself.

2. Are the requirements reasonable? Yes. PIV and OpenPGP-backed ssh-agent identities, pinentry, and PIN caching are a sensible first scope. Leaving age and the gpg-agent protocol for later makes sense.

3. What would a first merge take? Mostly a design we agree on before code. Structurally, keyroost was built around short, one-shot operations, and an agent changes that. The challenges I see:

• Long-lived sessions. Today every CLI or GUI action opens the card, does one thing and closes it. An agent keeps state across requests. It would need to handle keys being unplugged and replugged, reader changes, and suspend/resume.
• Sharing the card. keyroost connects in PC/SC shared mode, so the agent would contend with the GUI, the CLI, gpg/scdaemon, ykman and others. Another program selecting a different applet can reset PIV/OpenPGP state, including a verified PIN. We'd need transactions and a clear plan for re-verifying the PIN; PIV applet fingerprinting, device specific feature gates #128 is starting on transactions.
• PIN handling. Right now PINs arrive once (env or stdin), are used, and are wiped. An agent means pinentry plus a cache: how long to keep it, clearing it on key removal, screen lock and suspend, and how it interacts with each slot's PIN policy.
• Security surface. It would be a long-running process holding cached PINs behind a socket. That raises socket permissions, agent forwarding, confirm-on-use (touch policy), and logging that never leaks anything.
• Protocols and formats. The ssh-agent protocol and Assuan (pinentry) are small, and the project prefers in-tree code to new dependencies where that's reasonable. There's also SSH key and signature encoding for RSA, ECDSA and Ed25519. The transport layer can already sign for both PIV and OpenPGP.
• Platforms. A Unix socket covers Linux and macOS. Windows' OpenSSH uses a named pipe; is Windows in scope?
• Where it lives. I'd lean towards a separate crate and binary (e.g. keyroost-agent) rather than a keyroostctl subcommand. That keeps the management CLI lean, and keeps a spin-off into its own project cheap if that turns out to be the right home. It also means that users of keyroost can decide whether or not they want this capability instead of being forced to accept it.
• The GUI. keyroost aims for CLI/GUI feature parity. What, if anything, should the GUI do for an agent: start and stop it, show which identities it exposes, show the PIN cache state?

4. Subcommand or separate binary? See "Where it lives" above: separate, at least to start.

Questions for everyone:

• What would you want from a keyroost agent that piv-agent, gpg-agent, yubikey-agent or ssh-agent with PKCS#11 doesn't give you today?
• How should it be structured: in this repo as its own crate, or a sibling project using keyroost's published crates?
• Which platforms and applets are must-haves for you?
• How should PIN caching behave by default?

@plaflamme, please keep iterating on the prototype in your fork. It's the best way to find out what keyroost's libraries would need to change. Anything that turns out to be a general improvement to the transport crates is welcome as its own PR in the meantime.

[plaflamme]

apologies for the lack of response, life gets in the way sometimes.

No worries, I wasn't sure if "Discussions" were as visible as issues or PRs... Thanks for considering this.

It might even be better as a sibling project built on keyroost's crates than as part of keyroost itself.

Yes, that's fair. I can make this a separate project and perhaps it eventually gets folded into the keyroost repository. I'm probing for interest because I'd rather not have to maintain something like this forever. Seems like a good sub-project of the keyroost "ecosystem" eventually.

Long-lived sessions.

and

Sharing the card.

The current implementation does not keep sessions opened: it opens a session, does "one" thing and then closes it again. This is simple, but probably not an efficient use of the card. Ideally, we'd cache things internally, but then this requires detecting that the cache is stale somehow which seems tricky. I believe this is the most important thing to get right because it will directly affect the "UX" of the agent which matters quite a lot ultimately. Perhaps configuration can help mitigate issues that users encounter as well.

PIN handling.

The agent will cache the pin eventually and respect the slot's pin policy. We will likely need to integrate OS-specific crate to detect when the OS when to sleep or the screen was locked to bust this cache.

Platforms ... is Windows in scope?

I'm not personally interested in that, but presumably possible.

Again, thanks for considering this. I will keep iterating on this and see where it goes

[framefilter]

@plaflamme looking forward to seeing where it goes. I am truly humbled that anyone would give this project the time of day, let alone actively contribute to it and riff off of it. I understand the lack of interest in Windows, though I am doing my best to support it as Rust has fairly good tooling for Linux, MacOS, and Windows. It's been a learning curve though.

[n0xena]

As for "keeping a session -> keeping an exclusive lock": It was exactly that quirk of GnuPG that pushed my towards piv/x509/implement my own stuff: GnuPG has the very bad habbit of grabbing an exclusive lock and not releasing it after the operation is done. As long as one stays within that eco system like for git commit signing or pushing via ssh that's all fine.
But: if one want to use the same key for other purposes, like fido/webauthn/passkeys, a browser can't access the key because it's still locked by GnuPG. It requires either an explicit gpg-card reset, a hard replug or killing the running daemon to get access to the token again.
So, however this might get implemented, please don't redo GnuPGs mistake and make sure to properly release any locks so other features of tokens, like passkeys, can be used properly.
I'm not sure if or how that's possible, but if it causes inconvenience because a user has to re-enter a pin for a gpg session because they logged into a website using a passkey, that should be the way to go. At least for me reentering a pin is less painfull than to somehow get my "stuck" token free again.
I guess the most annoying part will be to properly handle git commit signing and how git depends on a GnuPG works with a second data stream to report the successfull operation. On Linux it's quite simple to parse the FD id given as parameter and access /proc/self/fd/ and maybe something similar works on BSD/Mac - but how handle that on Windows?
I once tried to write a shim in Java, and although i got a valid signature I wasn't able to figure out how to reply back to git correctly.