Re: [PATCH] ssh signing: Support ECDSA as literal SSH keys

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 7, 2022, 17:20 UTC
Message-ID: <xmqqtu8wxue8.fsf@gitster.g>
In-Reply-To: <20220607085226.g6sjcmoiimcvqknx@fs>

Fabian Stelzer <fs@gigacodes.de> writes:

Show 17 quoted lines

> On 01.06.2022 00:05, Junio C Hamano wrote:
>>Fabian Stelzer <fs@gigacodes.de> writes:
>>
>>>>Thanks for replying, Fabian.
>>>>
>>>>My main issue is that ecdsa-sha2-* keys currently seem incompatible
>>>>with `gpg.ssh.defaultKeyCommand = "ssh-add -L"`
>>>>
>>>>The git-config documentation of `gpg.ssh.defaultKeyCommand` says:
>>>>
>>>>> To automatically use the first available key from your ssh-agent set this to "ssh-add -L".
>>
>>This is puzzling.  One chooses the key to use when signing, and the
>>key should go to the gpg.ssh.defaultkey, and also "ssh-add" is told
>>about the key for convenient access.
>
> I think you mean `user.siningKey` but yes, this is the best way to do this.

Thanks for seeing my intention through my mistake.

Show 16 quoted lines

>> Asking "ssh-add -L" about the
>>keys it knows about and randomly pick the first one it happens to
>>tell you about sounds totally backwards to me.
>>
>>I may have a key I use to sign, and one key each to go to various
>>destinations, all of which "ssh-add -L" may know about.  It alone
>>cannot fundamentally tell because it does not know what you intend
>>to use each key for.
>> ...
>>In any case, perhaps we should extend the documentation a bit.  It
>>generally is not sensible to just use "ssh-add -L" and pick one
>>random key out of it, so we shouldn't be encouraging such a use, I
>>suspect.
>
> Yes, I think that reasonable. The script can do some advanced decision
> making / key lookup if needed.

OK.

> The use-case for me was to enforce/encourage use of the correct
> users keys on a shared development server in a corporate
> environment (i have a global directory of all the users keys and
> want to make sure everyone uses their correct one when signing).

I actually wanted to hear more about the reasoning along that line.

IOW, "sure, theoretically, you should start from 'this is the key I want to use' and you shouldn't be asking 'ssh-add -L' about it, but here is a real-world workflow that makes it cumbersome" was what I wanted to see, both in the discussion *and* in the documentation update.

For example, there may be corporate environment where key is frequently rotated, e.g. every morning an employee may have to "corp login" to talk to a central key server and get the ssh key stored in their hardware token refreshed. In such an environment, it would not be surprising if the employee does not even know what the fingerprint or the public part of the key looks like before asking 'ssh-add -L' to query the hardware token, so it may be impractical to follow the "set your key to user.signingKey and add that to the agent". Asking the agent about the key may make perfect sense (but you'd probably need to find which key among its output lines) in such a case.