git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Fabian Stelzer <fs@gigacodes.de>
Date
Jun 7, 2022, 08:52 UTC
Message-ID
<20220607085226.g6sjcmoiimcvqknx@fs>
In-Reply-To
<xmqqa6awvp60.fsf@gitster.g>
On 01.06.2022 00:05, Junio C Hamano wrote:
Show 14 quoted lines
>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.
Show 27 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.
>
>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.
Previous: Junio C HamanoNext: Junio C Hamano
Message 6 of 9 in “ssh signing: Support ECDSA as literal SSH keys”
  1. ssh signing: Support ECDSA as literal SSH keysAndy Lindeman via GitGitGadget, May 30, 2022
  2. Fabian StelzerMay 31, 2022
  3. Andy LindemanMay 31, 2022
  4. Fabian StelzerMay 31, 2022
  5. Junio C HamanoJun 1, 2022
  6. Fabian StelzerJun 7, 2022
  7. Junio C HamanoJun 7, 2022
  8. gpg docs: explain better use of ssh.defaultKeyCommandFabian Stelzer, Jun 8, 2022
  9. Andy LindemanJun 13, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.