[pve-devel] [PATCH docs 2/2] ssh: document PVE-specific setup

[Esi Y]

On Fri, Jan 12, 2024 at 01:04:50PM +0000, Esi Y wrote:
> On Fri, Jan 12, 2024 at 01:40:44PM +0100, Fabian Grünbichler wrote:
> > 
> > > Esi Y via pve-devel <pve-devel at lists.proxmox.com> hat am 12.01.2024 13:33 CET geschrieben:
> > > On Thu, Jan 11, 2024 at 11:51:20AM +0100, Fabian Grünbichler wrote:
> > > > such as adapted configs and managed files.
> > > > 
> > > > Signed-off-by: Fabian Grünbichler <f.gruenbichler at proxmox.com>
> > > > ---
> > > > Notes: actual version needs to be inserted!
> > > > 
> > > >  pvecm.adoc | 18 ++++++++++++++++++
> > > >  1 file changed, 18 insertions(+)
> > > > 
> > > > diff --git a/pvecm.adoc b/pvecm.adoc
> > > > index 5b5b27b..3a32cfb 100644
> > > > --- a/pvecm.adoc
> > > > +++ b/pvecm.adoc
> > > > @@ -918,6 +918,24 @@ transfer memory and disk contents.
> > > >  
> > > >  * Storage replication
> > > >  
> > > > +SSH setup
> > > > +~~~~~~~~~
> > > > +
> > > > +On {pve} systems, the following changes are made to the SSH configuration/setup:
> > > > +
> > > > +* the `root` user's SSH client config gets setup to prefer `AES` over `ChaCha20`
> > > > +
> > > > +* the `root` user's `authorized_keys` file gets linked to
> > > > +  `/etc/pve/priv/authorized_keys`, merging all authorized keys within a cluster
> > > 
> > > Will you be opening a new fix # thread on this one or intending to keep it as-is (even as the known_hosts changes are rolled out)?
> > 
> > see the cover letter - if this series gets applied in its current form, then changing the (client) key setup (both the keys used, and the authorized keys handling) would be a potential (but not required) follow-up. the main issue with that is that setups out there might rely on the current behaviour (e.g., ssh-copy-id to one node registering the key automatically with all nodes in the cluster), so it's likely only possible to switch by default on the next major bump, if we decide to go down that route.
> 
> I read the cover, I was just surprised it goes into the docs now as if already decided on. The backwards compatibility until next major could be retained if this was implemented (also) with AuthorizedKeysCommand. That way also logging of potential issues coming up with the next major could be used as a cue in upgrade script, i.e. if there were any uses of the "old" keys from the shared location.

Somehow forgotten to include the list. This is analogous suggestion to the KnownHostsCommand to avoid relying on -o's.