patchssh signing: Support ECDSA as literal SSH keys

>From: Andy Lindeman <andy@lindeman.io>
>
>Keys generated using `ssh-keygen -t ecdsa` or similar are being rejected
>as literal SSH keys because the prefix is `ecdsa-sha2-nistp256`,
>`ecdsa-sha2-nistp384` or `ecdsa-sha2-nistp521`.
>
>This was acknowledged as an issue [1] in the past, but hasn't yet been
>fixed.

>
>[1]: https://github.com/git/git/pull/1041#issuecomment-971425601
>
>Signed-off-by: Andy Lindeman <andy@lindeman.io>
>---
>    ssh signing: Support ECDSA as literal SSH keys
>
>    Keys generated using ssh-keygen -t ecdsa or similar will currently be
>    rejected as literal SSH keys because the prefix is ecdsa-sha2-nistp256,
>    ecdsa-sha2-nistp384 or ecdsa-sha2-nistp521.
>
>    This was acknowledged as an issue in the past, but hasn't yet been
>    fixed.
>
>    https://github.com/git/git/pull/1041#issuecomment-971425601
>
>Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1272%2Falindeman%2Fecdsa-sha2-keys-v1
>Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1272/alindeman/ecdsa-sha2-keys-v1
>Pull-Request: https://github.com/git/git/pull/1272
>
> gpg-interface.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/gpg-interface.c b/gpg-interface.c
>index 280f1fa1a58..086bd03b51d 100644
>--- a/gpg-interface.c
>+++ b/gpg-interface.c
>@@ -779,7 +779,7 @@ static int is_literal_ssh_key(const char *string, const char **key)
> {
> 	if (skip_prefix(string, "key::", key))
> 		return 1;
>-	if (starts_with(string, "ssh-")) {
>+	if (starts_with(string, "ssh-") || starts_with(string, "ecdsa-sha2-")) {
> 		*key = string;
> 		return 1;
> 	}
>
>base-commit: 8ddf593a250e07d388059f7e3f471078e1d2ed5c
>-- 
>gitgitgadget

> On 30.05.2022 17:45, Andy Lindeman via GitGitGadget wrote:
> >From: Andy Lindeman <andy@lindeman.io>
> >
> >Keys generated using `ssh-keygen -t ecdsa` or similar are being rejected
> >as literal SSH keys because the prefix is `ecdsa-sha2-nistp256`,
> >`ecdsa-sha2-nistp384` or `ecdsa-sha2-nistp521`.
> >
> >This was acknowledged as an issue [1] in the past, but hasn't yet been
> >fixed.
>
> Hi Andy,
> thanks for your report. We have decided in the past to not explicitly cater
> to every key prefix and instead use `key::` for literal keys.
> See
> https://git-scm.com/docs/git-config#Documentation/git-config.txt-usersigningKey
>
> `For backward compatibility, a raw key which begins with "ssh-", such as
> "ssh-rsa XXXXXX identifier", is treated as "key::ssh-rsa XXXXXX identifier",
> but this form is deprecated; use the key:: form instead.`

>On Tue, May 31, 2022 at 3:34 AM Fabian Stelzer <fs@gigacodes.de> wrote:
>> On 30.05.2022 17:45, Andy Lindeman via GitGitGadget wrote:
>> >From: Andy Lindeman <andy@lindeman.io>
>> >
>> >Keys generated using `ssh-keygen -t ecdsa` or similar are being rejected
>> >as literal SSH keys because the prefix is `ecdsa-sha2-nistp256`,
>> >`ecdsa-sha2-nistp384` or `ecdsa-sha2-nistp521`.
>> >
>> >This was acknowledged as an issue [1] in the past, but hasn't yet been
>> >fixed.
>>
>> Hi Andy,
>> thanks for your report. We have decided in the past to not explicitly cater
>> to every key prefix and instead use `key::` for literal keys.
>> See
>> https://git-scm.com/docs/git-config#Documentation/git-config.txt-usersigningKey
>>
>> `For backward compatibility, a raw key which begins with "ssh-", such as
>> "ssh-rsa XXXXXX identifier", is treated as "key::ssh-rsa XXXXXX identifier",
>> but this form is deprecated; use the key:: form instead.`
>
>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".
>
>But this does not work with ecdsa keys because each line of the output
>of the command is checked against `is_literal_ssh_key`. Because of
>that check, keys that do not begin with `ssh-` are skipped.

>
>The code that runs `defaultKeyCommand` states:
>
>> /*
>> * We only use `is_literal_ssh_key` here to check validity
>> * The prefix will be stripped when the key is used.
>> */
>
>but this is clearly not true because it is rejecting valid SSH keys.
>
>Do you have thoughts on how to improve `gpg.ssh.defaultKeyCommand` for
>keys whose prefix is not `ssh-` ?

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

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

> 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.
>
>Of course, as your own custom script, defaultKeyCommand may know
>which keys you intend to use for connecting and which keys you
>intend to use for signing.  It may even need to know which key you
>intend to use for each project you work with and your .git/config
>may have something to tell the script what "trait" the key to be
>used that appear in "ssh-add -L" output should have (perhaps the key
>is rotated very often so you cannot write the exact key in your
>configuration, but perhaps the comment at the end of each line have
>sufficient cue to tell them apart).  So, the custom script would
>need to go line by line to find the key to use in the first place,
>and if it is computationally capable enough to do so, it should be
>easy to prefix key:: in front.  IIRC, we designed the system in such
>a way that it is not an error to prefix key:: in front of ssh-* keys.
>
>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.

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

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

>
> Using `ssh-add -L` for gpg.ssh.defaultKeyCommand is not a good
> recommendation. It might switch keys depending on the order of known
> keys and it only supports ssh-* and no ecdsa or other keys.
> Clarify that we expect a literal key prefixed by `key::`, give valid
> example use cases and refer to `user.signingKey` as the preferred
> option.
>
> Signed-off-by: Fabian Stelzer <fs@gigacodes.de>
> ---
>  Documentation/config/gpg.txt | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/config/gpg.txt b/Documentation/config/gpg.txt
> index 86892ada77..86f6308c4c 100644
> --- a/Documentation/config/gpg.txt
> +++ b/Documentation/config/gpg.txt
> @@ -36,9 +36,12 @@ gpg.minTrustLevel::
>
>  gpg.ssh.defaultKeyCommand::
>         This command that will be run when user.signingkey is not set and a ssh
> -       signature is requested. On successful exit a valid ssh public key is
> -       expected in the first line of its output. To automatically use the first
> -       available key from your ssh-agent set this to "ssh-add -L".
> +       signature is requested. On successful exit a valid ssh public key
> +       prefixed with `key::` is expected in the first line of its output.
> +       This allows for a script doing a dynamic lookup of the correct public
> +       key when it is impractical to statically configure `user.signingKey`.
> +       For example when keys or SSH Certificates are rotated frequently or
> +       selection of the right key depends on external factors unknown to git.
>
>  gpg.ssh.allowedSignersFile::
>         A file containing ssh public keys which you are willing to trust.
> --
> 2.35.3
>