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