--- Begin Message ---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@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.gruenbich...@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.
--- End Message ---
_______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
