From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE, URIBL_CSS,URIBL_CSS_A shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by dcvr.yhbt.net (Postfix) with ESMTP id 598E21F4D7 for ; Tue, 7 Jun 2022 17:20:56 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; unprotected) header.d=pobox.com header.i=@pobox.com header.b="Y/WPqGs1"; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345857AbiFGRUn (ORCPT ); Tue, 7 Jun 2022 13:20:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44558 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240037AbiFGRUi (ORCPT ); Tue, 7 Jun 2022 13:20:38 -0400 Received: from pb-smtp21.pobox.com (pb-smtp21.pobox.com [173.228.157.53]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9BD231053DD for ; Tue, 7 Jun 2022 10:20:36 -0700 (PDT) Received: from pb-smtp21.pobox.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id EEB46198706; Tue, 7 Jun 2022 13:20:35 -0400 (EDT) (envelope-from junio@pobox.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=r0lCPIT5Z0Ir9meg55+SyLIXMSVnoWl9KuDcPm wv0lI=; b=Y/WPqGs13lhJaZrfj5VntpPms7yy4xWNrvrUPNL28O2jv08J7kaoX5 pU5qDHba5Mpq9gJtZIjARy+cXgnwUiedBqOAZBTL6oSfonPQd5DFUBGScO7rcQLq fHuUZi9K4ub1sFFVDSMSJx48VfoRtM95bYZg9dT5gis/Nx2J7mAVw= Received: from pb-smtp21.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id E5DA5198705; Tue, 7 Jun 2022 13:20:35 -0400 (EDT) (envelope-from junio@pobox.com) Received: from pobox.com (unknown [34.83.92.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp21.pobox.com (Postfix) with ESMTPSA id 4A271198704; Tue, 7 Jun 2022 13:20:32 -0400 (EDT) (envelope-from junio@pobox.com) From: Junio C Hamano To: Fabian Stelzer Cc: Andy Lindeman , Andy Lindeman via GitGitGadget , git@vger.kernel.org Subject: Re: [PATCH] ssh signing: Support ECDSA as literal SSH keys References: <20220531073445.iuovy634ufp5xims@fs> <20220531144703.jbawf3tkypt7se2i@fs> <20220607085226.g6sjcmoiimcvqknx@fs> Date: Tue, 07 Jun 2022 10:20:31 -0700 In-Reply-To: <20220607085226.g6sjcmoiimcvqknx@fs> (Fabian Stelzer's message of "Tue, 7 Jun 2022 10:52:26 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: 22A96050-E686-11EC-8912-CBA7845BAAA9-77302942!pb-smtp21.pobox.com Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Fabian Stelzer writes: > On 01.06.2022 00:05, Junio C Hamano wrote: >>Fabian Stelzer 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.