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 gerrit.example.com
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?
Cheers,
Tim
Hello, openssh at tr.id.au wrote on 9. Mar 2024 00:39 (GMT +01:00):> 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.I would use a password manager with ssh-agent integration like KeePass, instead. But if you want to have the same level of protection (not exportable keys) you would need to store the key on the token with smartcard interface. But having a command to provide the key is a good idea. There are so many Solutions for using short lived certificates or one time keys for SSO, Bastions, Cloud IaM and automatically,provisioned,identities, they would be able To avoid wrappers when they have such an option. (For your usecase in particular I would not use it). Gru? Bernd ? https://bernd.eckenfels.net
On 08/03/2024 23:39, openssh at tr.id.au wrote:> 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.If you're using physical security keys, then some vendors include the ability to store one or two SSH RSA private keys in them as well (e.g. Yubikey). If Gerrit and Jenkins accept certs, then another approach would be to have an out-of-band certificate issuance process using whatever authentication you like. I believe Rory Campbell-Lange's sshagentca <https://github.com/rorycl/sshagentca> will let you use an sk to prove your identity, and then will issue you with a fresh ED25519 signed by the CA key (and place it directly in the client's ssh agent) Similarly, you can use Hashicorp's Vault to issue certificates (if you can stomach the new BSL license) using a range of different authentication mechanisms, although sk isn't one of them. I wrote vault-ssh-agent-login <https://github.com/candlerb/vault-ssh-agent-login> to insert a new key & cert into the local ssh agent.
On Fri, 8 Mar 2024, openssh at tr.id.au 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 gerrit.example.com > 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 https://pkg.go.dev/golang.org/x/crypto/ssh/agent#Agent -d