> Esi Y via pve-devel <pve-devel@lists.proxmox.com> hat am 09.01.2024 06:01 CET > geschrieben: > On Thu, Dec 21, 2023 at 10:53:11AM +0100, Fabian Grünbichler wrote: > > RFC since this would be a bigger change in how we approach intra-cluster > > SSH access. > > > > 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: > > > > - get_vnc_connection_info in PVE::API2::Nodes > > - 'upload' API endpoint in PVE::API2::Storage::Status > > - SSH proxy in pvesh > > > > these changes would need to happen coordinated with the patches from > > this RFC series! > > Not necessarily.
if we do the unmerge as well, then yes - else a node with unmerged known host would fail to connect to nodes that joined the cluster after unmerging. > > next steps afterwards: > > - unmerge known hosts in `pvecm updatecerts`, instead of merging > > -- to disentangle regular ssh from intra-cluster SSH > > 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/refresh > does not need to propagate any individual keys around the cluster; meanwhile yes it does, changing the key would entail revoking the old one (and distributing 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 additional 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 > > Will always work with local-only files. In the other approach, the -R will > 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 unmerging the known hosts to get rid of the symlink. > > -- existing keys would still be preserved for not-yet-upgraded nodes, so > > this > > should be do-able without waiting for a major release.. > > With the ssh certs, the old (non-cert) keys could be safely left behind in > the pmxcfs location, upgraded nodes would append the previously shared > content 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 work. > 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 file > > > - 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) > > 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 comparison > 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. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
