xref:pvecm_corosync_addresses[Link Address Types]).
In this example, we want to switch cluster communication to the
-10.10.10.1/25 network, so we change the 'ring0_addr' of each node respectively.
+10.10.10.0/25 network, so we change the 'ring0_addr' of each node respectively.
NOTE: The exact same procedure can be used to change other 'ringX_addr' values
as well. However, we recommend only changing one link address at a time, so
* Storage replication
-.Pitfalls due to automatic execution of `.bashrc` and siblings
-[IMPORTANT]
-====
+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
+
+* `sshd` is configured to allow logging in as root with a password
+
+NOTE: Older systems might also have `/etc/ssh/ssh_known_hosts` set up as symlink
+pointing to `/etc/pve/priv/known_hosts`, containing a merged version of all
+node host keys. This system was replaced with explicit host key pinning in
+`pve-cluster <<INSERT VERSION>>`, the symlink can be deconfigured if still in
+place by running `pvecm updatecerts --unmerge-known-hosts`.
+
+Pitfalls due to automatic execution of `.bashrc` and siblings
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
In case you have a custom `.bashrc`, or similar files that get executed on
login by the configured shell, `ssh` will automatically run it once the session
is established successfully. This can cause some unexpected behavior, as those
*) return;;
esac
----
-====
-
Corosync External Vote Support
------------------------------
The SSH key from the cluster will be automatically copied to the QDevice.
-NOTE: Make sure that the SSH configuration on your external server allows root
-login via password, if you are asked for a password during this step.
+NOTE: Make sure to setup key-based access for the root user on your external
+server, or temporarily allow root login with password during the setup phase.
If you receive an error such as 'Host key verification failed.' at this
stage, running `pvecm updatecerts` could fix the issue.
-After you enter the password and all the steps have successfully completed, you
-will see "Done". You can verify that the QDevice has been set up with:
+After all the steps have successfully completed, you will see "Done". You can
+verify that the QDevice has been set up with:
----
pve# pvecm status
https://manpages.debian.org/bookworm/libvotequorum-dev/votequorum_qdevice_master_wins.3.en.html].
* `NR`: QDevice is not registered.
+NOTE: If your QDevice is listed as `Not Alive` (`NA` in the output above),
+ensure that port `5403` (the default port of the qnetd server) of your external
+server is reachable via TCP/IP!
+
Frequently Asked Questions
~~~~~~~~~~~~~~~~~~~~~~~~~~