[pve-devel] [RFC cluster 0/2] fix #4886: improve SSH handling

[Esi Y]

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.
 
> 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:
1.  eliminate shared ssh config and key files, i.e. completely remove any need for symlinks; and
2.  instead initialise each node at join (first one at cluster creation) into their respective node-local files with ssh certs; whilst
3.  keeping the setup maintenance-free, since any single key addition/refresh does not need to propagate any individual keys around the cluster; meanwhile
4.  no requirement for additional -o options;
5.  no requirement for sshd config appends, just drop-ins;
6.  existing X509 CA key can be reused for ssh PKI as well.

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

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

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

What's the counter-argument to ssh certs, given the simlicity in comparison with both the old approach and the intially suggested one here?
 
> Fabian Gr?nbichler (2):
>   fix #4886: write node SSH hostkey to pmxcfs
>   fix #4886: SSH: pin node's host key if available
> 
>  src/PVE/Cluster/Setup.pm | 15 +++++++++++++++
>  src/PVE/SSHInfo.pm       | 15 ++++++++++++++-
>  2 files changed, 29 insertions(+), 1 deletion(-)
> 
> -- 
> 2.39.2
> 
> 
>