From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 34527BFC02 for ; Tue, 9 Jan 2024 09:58:02 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 16F0B14A04 for ; Tue, 9 Jan 2024 09:57:32 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Tue, 9 Jan 2024 09:57:31 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 42ED945269; Tue, 9 Jan 2024 09:57:31 +0100 (CET) Date: Tue, 9 Jan 2024 09:57:30 +0100 (CET) From: =?UTF-8?Q?Fabian_Gr=C3=BCnbichler?= To: Proxmox VE development discussion Cc: Esi Y Message-ID: <2097752910.1256.1704790650291@webmail.proxmox.com> In-Reply-To: References: <20231221095313.156390-1-f.gruenbichler@proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.6-Rev57 X-Originating-Client: open-xchange-appsuite X-SPAM-LEVEL: Spam detection results: 0 AWL 0.064 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pve-devel] [RFC cluster 0/2] fix #4886: improve SSH handling X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2024 08:58:02 -0000 > Esi Y via pve-devel hat am 09.01.2024 06:01= CET geschrieben: > On Thu, Dec 21, 2023 at 10:53:11AM +0100, Fabian Gr=C3=BCnbichler wrote: > > RFC since this would be a bigger change in how we approach intra-cluste= r > > SSH access. > >=20 > > there are still a few parts that currently don't use SSHInfo, but > > would need to be switched over if we want to pursue this approach: > >=20 > > - get_vnc_connection_info in PVE::API2::Nodes > > - 'upload' API endpoint in PVE::API2::Storage::Status > > - SSH proxy in pvesh > >=20 > > these changes would need to happen coordinated with the patches from > > this RFC series! >=20 > Not necessarily. if we do the unmerge as well, then yes - else a node with unmerged known ho= st would fail to connect to nodes that joined the cluster after unmerging. =20 > > next steps afterwards: > > - unmerge known hosts in `pvecm updatecerts`, instead of merging > > -- to disentangle regular ssh from intra-cluster SSH >=20 > Both of these could be accomplished with codebase/complexity reduction in= an approach to: I am not sure what "both" means here? there is only a single thing quoted ;= ) > 1. eliminate shared ssh config and key files, i.e. completely remove any= need for symlinks; and that's the evaluate part further below. > 2. instead initialise each node at join (first one at cluster creation) = into their respective node-local files with ssh certs; whilst versus just copying the host key, which is far simpler? > 3. keeping the setup maintenance-free, since any single key addition/ref= resh does not need to propagate any individual keys around the cluster; mea= nwhile yes it does, changing the key would entail revoking the old one (and distri= buting that!) and signing the new one. > 4. no requirement for additional -o options; we already need -o options anyway, so there is no downside to adding additi= onal ones > 5. no requirement for sshd config appends, just drop-ins; there's no need for sshd config changes either with the patches here? > 6. existing X509 CA key can be reused for ssh PKI as well. that might no actually be the best of ideas ;) > > -- to allow `ssh-keygen -f .. -R ..` to work properly again >=20 > Will always work with local-only files. In the other approach, the -R wil= l still not work with a file stored on pmxcfs. yes, the -R will work with a file stored on pmxcfs. just not with a symlink= , no matter where it points. which is why the next step above lists unmergi= ng the known hosts to get rid of the symlink. =20 > > -- existing keys would still be preserved for not-yet-upgraded nodes, s= o this > > should be do-able without waiting for a major release.. >=20 > With the ssh certs, the old (non-cert) keys could be safely left behind i= n the pmxcfs location, upgraded nodes would append the previously shared co= ntent into local files, old nodes would not make use of the new keys until = upgraded, but will keep working with the old to the extent they used to wor= k. Universal remedy for any legacy issues would be to upgrade the node. the same is true for the patches here: - updated nodes publish their own key, and use published keys if available - non-updated nodes will still have the symlink and use the "old" merged fi= le >=20 > > - evaluate whether we want to split out > > -- the client config (we currently force a cipher order there) > > -- the client key (could live in /etc/pve/priv instead?) > > -- or even the sshd instance altogether (would allow not touching the > > regular sshd config at all) >=20 > Non-issue in the ssh certs approach. on the contrary, all of the above are also valid for cert-based auth.. > What's the counter-argument to ssh certs, given the simlicity in comparis= on with both the old approach and the intially suggested one here? the one sentence summary - it doesn't get us closer to where we want to end= up (either getting rid of SSH entirely, or full disentangling PVE-internal= SSH use from the regular, default sshd instance), but adds more complexity= instead.