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

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

[Andy Lindeman via GitGitGadget]

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

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

[Fabian Stelzer]

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

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

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

[Andy Lindeman]

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.

I could certainly write my own shell script for `defaultKeyCommand`
that did something like `ssh-add -L | sed 's/^/key::/'` but it's a bit
awkward.

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-` ?

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

[Fabian Stelzer]

On 31.05.2022 09:28, Andy Lindeman wrote:
>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.

True, this is a bug.

>
>I could certainly write my own shell script for `defaultKeyCommand`
>that did something like `ssh-add -L | sed 's/^/key::/'` but it's a bit
>awkward.

I think this is at least a valid workaround for now.

>
>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-` ?

The problem is that we do not want to maintain all ssh keytypes in the git 
code. Thats why the `key::` was added.
I'll have to think what we could do besides just skipping the check 
completely and just assuming the defaultKeyCommand will return a valid key.
ssh-add -L is not necessarily defined as having a parsable output and any 
additional messages it might print (or some pkcs11 provider) would at least 
be skipped with the ssh- prefix check.

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

[Junio C Hamano]

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.

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

[Fabian Stelzer]

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

Yes, I think that reasonable. The script can do some advanced decision 
making / key lookup if needed. 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'll take a look at the docs and suggest a patch in a bit.

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

[Junio C Hamano]

Fabian Stelzer <fs@gigacodes.de> writes:

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

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

[PATCH] gpg docs: explain better use of ssh.defaultKeyCommand

[Fabian Stelzer]

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

Re: [PATCH] gpg docs: explain better use of ssh.defaultKeyCommand

[Andy Lindeman]

On Wed, Jun 8, 2022 at 11:24 AM Fabian Stelzer <fs@gigacodes.de> wrote:
>
> 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
>

Nice. This makes sense to me.