On 31.05.2022 09:28, Andy Lindeman wrote:
On Tue, May 31, 2022 at 3:34 AM Fabian Stelzer <fs@xxxxxxxxxxxx> wrote:
On 30.05.2022 17:45, Andy Lindeman via GitGitGadget wrote:
>From: Andy Lindeman <andy@xxxxxxxxxxx>
>
>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.
