Closed lxgr closed 2 years ago
Yeah I'm tracking this on https://github.com/maxgoedjen/secretive/issues/348 – it's something I'd like to have (mainly the pass-through version) but it's a bit tricky – reading keys directly would mean implementing a bunch of other key types I haven't yet (RSA, etc). Pass-through might be feasible, but I need to see how difficult talking to the system agent would be.
@lxgr just out curiosity, what's the experience like now for you? Just testing it here, ssh seems to attempt to use the on-disk keys if the agent doesn't have a key that the server accepts. I don't have any passworded keys though, is that what's causing the issue?
Yes, that's exactly the issue – I am able to use on-disk keys, but I have to enter their passphrases every time.
FWIW, I built a simple app to multiplex multiple ssh agents into one, and another to filter agents down to specific keys by their fingerprints.
I needed the multiplexer because I have to use Secretive along with Yubikeys, regular SSH keys, and all with agent forwarding.
I needed the filter because GitHub will accept the first offered identity it knows about, and reject access if it's the wrong identity for a given repo.
These won't be useful to this project directly, since I've written everything in Go. But if this sounds useful to anyone else, I'd love to hear more about your specific use cases. I'll get the code cleaned up and on GitHub in a day or so.
https://github.com/jnoxon/ssh-agent-utils is the repo in question, I assume. Leaving it here for future reference.
Would it be possible for secretive to offer something like "agent passthrough"?
This could address the following scenario: I have one key stored in the Secure Enclave, but several legacy file-based secret keys (either because I don't have access to some server's
authorized_keys
, e.g. for SFTP-only accounts, or because these servers don't supportecdsa-sha2-nistp256
), which I'd normally use through the defaultssh-agent
. With secretive, I currently have to make a per-host decision to use a different agent (e.g. via a corresponding.ssh/config
setting) or alternatively enter a passphrase for the file-based keys.Not sure how feasible something like this is, but could secretive possibly be a client to the system
ssh-agent
itself, passing through key names and operations as required?Alternatively, I suppose secretive could also act as an agent for these file-based keys itself (possibly storing the passphrase or caching the decrypted key in the Secure Enclave itself, which would allow optional biometric authentication just like for "native" SE keys).