PrivateKeyCommand config idea

Jan Schermer jan at
Mon Mar 11 03:05:24 AEDT 2024

The problem with those IDEs (IDEA, XCode…) is that they use their own implementationand rarely even listen to whatever little settings they could understand in ~/.ssh/config.
So even if you “fake” the right key type for them (which you can btw using Resident keys), they won’t ever use the physical security key anyway and either completely ignore it or throw an error.
The right solution is to force those vendors to get in line and use standard tools which are not dependent on what they decided to implement 10 years ago when they discovered pubkeys instead of passwords (yes, there was a time when even having pubkey support was a luxury and the IDE kept asking you for a password).


> On 10. 3. 2024, at 9:38, Damien Miller <djm at> wrote:
> On Fri, 8 Mar 2024, openssh at wrote:
>> G'day,
>> In our infrastructure we're trying to be more diligent about switching
>> to sk keys (and/or certs backed by sk keys.) However, there are some
>> services like Gerrit and Jenkins which are written in java and I guess
>> they will never support sk keys, or at least, it seems like it won't
>> happen any time soon.
>> For such services, typical practices at the moment include putting
>> passphrases on the keys using OpenSSH's built-in AES128 encryption,
>> and using GnuPG's ssh integration to create gpg-backed keys. These
>> existing solutions cause various inconveniences, like needing to
>> switch to a different terminal to get the passphrase out of Pass,
>> or running into problems when trying to do agent-forwarding with
>> gpg-backed keys on non-Linux OSes. Even on Linux, I think such a
>> workflow can be a bit flaky at times.
>> I wondered if there would be support for adding a new configuration
>> option called something like PrivateKeyCommand, analogous to existing
>> "*Command" configs like AuthorizedKeysCommand. In practice I imagine
>> it looks like this:
>>  Host
>>     PrivateKeyCommand pass show ssh/gerrit_ed25519
>> I suppose another possibility for the name could be IdentityCommand,
>> analogous to IdentityFile.
>> If you like, and time permitting, I may be interested in trying to
>> implement such a patch -- but before I invest the work, I wondered if
>> there would be support for including it, or would it introduce some
>> sort of issue that I've probably overlooked?
> Would you be able to do this using the ssh-agent protocol? It's
> relatively easy to make custom agent implentations for special use
> cases, e.g. using
> -d
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at

More information about the openssh-unix-dev mailing list