Mailing List Archive: PrivateKeyCommand config idea

PrivateKeyCommand config idea

Mar 8, 2024, 3:39 PM

Post #1 of 11 (182 views)

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

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Re: PrivateKeyCommand config idea [ In reply to ]

ecki at zusammenkunft

Mar 9, 2024, 12:26 AM

Post #2 of 11 (182 views)

Permalink

Hello,

openssh@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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Re: PrivateKeyCommand config idea [ In reply to ]

b.candler at pobox

Mar 9, 2024, 1:04 AM

Post #3 of 11 (182 views)

Permalink

On 08/03/2024 23:39, openssh@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.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Re: PrivateKeyCommand config idea [ In reply to ]

djm at mindrot

Mar 9, 2024, 11:38 PM

Post #4 of 11 (181 views)

Permalink

On Fri, 8 Mar 2024, openssh@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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Re: PrivateKeyCommand config idea [ In reply to ]

wiktor at metacode

Mar 10, 2024, 3:58 AM

Post #5 of 11 (180 views)

Permalink

Hi,

There is a project that allows exposing GPG encrypted private SSH keys through ssh agent protocol: https://crates.io/crates/ssh-gpg-agent

I never used that, but it looks very similar to your design with pass (which internally uses gpg).

Kind regards,
Wiktor
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Re: PrivateKeyCommand config idea [ In reply to ]

jan at schermer

Mar 10, 2024, 9:05 AM

Post #6 of 11 (179 views)

Permalink

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

Jan

> On 10. 3. 2024, at 9:38, Damien Miller <djm@mindrot.org> wrote:
>
> On Fri, 8 Mar 2024, openssh@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://www.google.com/url?q=https://pkg.go.dev/golang.org/x/crypto/ssh/agent%23Agent&source=gmail-imap&ust=1710664868000000&usg=AOvVaw3GLMtEPm-TjZNfYgovCSEq
>
> -d
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://www.google.com/url?q=https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev&source=gmail-imap&ust=1710664868000000&usg=AOvVaw1I0uVzabFeaIV5RCpwo9TE

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Re: PrivateKeyCommand config idea [ In reply to ]

openssh at tr

Mar 11, 2024, 2:15 PM

Post #7 of 11 (172 views)

Permalink

Hey Damien,

> 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

Hmm, okay, I just realized the protocol has a full specification at https://datatracker.ietf.org/doc/html/draft-miller-ssh-agent. Would it be possible to get that protocol added to the list of manuals which typically get installed with the OpenSSH package?

Previously I was stumbling around in the dark based on what I can see in the manpages and stackexchange. With the protocol, I can see how I might be able to end up with something close to my requirements.

As Bernd said, there could be other uses for a new config like the one I requested. However, if I can get what I want from existing methods, then I probably wouldn't continue trying to implement something else :)

Thanks for your time!

~ Tim

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Re: PrivateKeyCommand config idea [ In reply to ]

ecki at zusammenkunft

Mar 11, 2024, 6:05 PM

Post #8 of 11 (172 views)

Permalink

BTW not for your usecase with the decryption, but if people want to dynamically create/provision short lived
keys, they could use „match host * exec gen-key.sh %s“ config to run a program before each connection.
However it can’t stdout the key material, but what it could do is update a temporary Idendity file or
push it short-lived with ssh-add to the running (standard) agent.

openssh@tr.id.au wrote on 11. Mar 2024 22:15 (GMT +01:00):

> Hmm, okay, I just realized the protocol has a full specification at
> https://datatracker.ietf.org/doc/html/draft-miller-ssh-agent. Would it be
> possible to get that protocol added to the list of manuals which typically
> get installed with the OpenSSH package?
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Re: PrivateKeyCommand config idea [ In reply to ]

ecki at zusammenkunft

Mar 11, 2024, 6:05 PM

Post #9 of 11 (172 views)

Permalink

BTW not for your usecase with the decryption, but if people want to dynamically create/provision short lived
keys, they could use „match host * exec gen-key.sh %s“ config to run a program before each connection.
However it can’t stdout the key material, but what it could do is update a temporary Idendity file or
push it short-lived with ssh-add to the running (standard) agent.

openssh@tr.id.au wrote on 11. Mar 2024 22:15 (GMT +01:00):

> Hmm, okay, I just realized the protocol has a full specification at
> https://datatracker.ietf.org/doc/html/draft-miller-ssh-agent. Would it be
> possible to get that protocol added to the list of manuals which typically
> get installed with the OpenSSH package?

Gruß
Bernd
—
https://bernd.eckenfels.net
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Re: PrivateKeyCommand config idea [ In reply to ]

luto at kernel

Mar 11, 2024, 7:11 PM

Post #10 of 11 (172 views)

Permalink

On Mon, Mar 11, 2024, at 6:05 PM, Bernd Eckenfels wrote:
> BTW not for your usecase with the decryption, but if people want to
> dynamically create/provision short lived
> keys, they could use „match host * exec gen-key.sh %s“ config to run a
> program before each connection.
> However it can’t stdout the key material, but what it could do is
> update a temporary Idendity file or
> push it short-lived with ssh-add to the running (standard) agent.

I posted earlier about this -- it works very poorly. In particular, it runs even in cases where nothing is trying to connect. For example:

ssh -O exit host

I personally think the ssh-agent suggestion works poorly. It's fine if one's goal is to configure an agent for all connections made by the running user. But if you want to do it *per host*, then something needs to start the agent and something needs to tell it when it's done.

I can imagine this being improved in a couple ways. For example, there could be an option like:

IdentityAgentCommand foo

where foo is run and the agent protocol is spoken over stdin and stdout. Or maybe the command could pass a connected socket back to its caller (via an awkward SCM_RIGHTS dance) so that the caller wouldn't be forced to remain running.

--Andy
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Re: PrivateKeyCommand config idea [ In reply to ]

openssh at tr

Mar 11, 2024, 8:02 PM

Post #11 of 11 (172 views)

Permalink

Hey Andy,

Thanks for your input.

> I personally think the ssh-agent suggestion works poorly. It's fine if one's goal is to configure an agent for all connections made by the running user. But if you want to do it per host, then something needs to start the agent and something needs to tell it when it's done.

Personally, through a combination of sk keys, daily certificates, and ControlMasters, I don't usually have an agent on by default. Without a need to frequently cache passphrases, and preferring to avoid workflows that rely on agent forwarding, I only activate an agent selectively.

Part of what the IdentityCommand change would give me, if it were implemented, is I would no longer need to manually add ssh-agent to terminals or shells where I'll be running `git review` a lot :) I would just be able to make a one-line change to my ssh config and then everything will "just work" on every machine where I set things up identically.

As an aside, for general interest, when agents *are* needed, I have a Match stanza in client config to namespace ControlMasters. This helps avoid cross-talk between agents:

Match exec "[[ -n $SSH_AGENT_PID ]]"
ControlPath ~/.ssh/cm/agent-${SSH_AGENT_PID}_%r@%n:%p

Host *
ControlPath ~/.ssh/cm/%r@%n:%p

~ Tim

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev