12

I have a script that needs to connect to the currently active head of a high-availability cluster.

Each node in the cluster has a fixed hostname and IP address.
The current head additionally has a "virtual IP". In the case of a switchover or failover, another node configures the "virtual IP" and begins acting as the head.

Can I just point my script at the virtual IP? Won't ssh complain about mismatching host keys when the cluster moves the virtual IP to a different node?

3 Answers 3

19

Yes, this is possible.

sshd(8) (from OpenSSH) specifies the format of known_host files (in the section SSH_KNOWN_HOSTS FILE FORMAT):

When performing host authentication, authentication is accepted if any matching line has the proper key; […]

It is permissible (but not recommended) to have several lines or different host keys for the same names. This will inevitably happen when short forms of host names from different domains are put in the file. It is possible that the files contain conflicting information; authentication is accepted if valid information can be found from either file.

Therefore you can just add the host keys of both HA heads to your ~/.ssh/known_hosts or /etc/ssh/ssh_known_hosts:

203.0.113.50 ssh-rsa AAAAB3NzaC1yc2…6Yh5sHpkyIZvXLB
203.0.113.50 ssh-rsa AAAAB3NzaC1yc2…R0RNVnMB6C4plFr

and ssh will connect to both of them without any complaints.

1
  • My ~/.ssh/known_hosts file contains a hashed representation of names and ip with type ecdsa-sha2-nistp256 instead rsa, which can be determine by ssh-keyscan -H <server_ip>
    – Hölderlin
    Mar 7, 2023 at 11:24
6

Yes, n.st answer is correct.

But note, that OpenSSH clients since version 8.5 have ssh_config option UpdateHostKeys enabled by default, and with that enabled, the solution no longer works because the client automatically deletes all host keys that the connected host does not have (e.g. you have a service IP floating between two hosts, and each host has exclusively it's own host key) from the client's known_hosts file.

To prevent this, you need to set UpdateHostKeys no in your client's ~/.ssh/config file to restore the old behavior.

1

While it is just possible that this might be a valid question, in the majority of cases, this is the XY problem.

First, floating IPs suck as a high availbility solution. There are some cases where it's just not practical to implement a better solution but these are rare (e.g. the address of the default gateway).

Unless the primary purpose of the cluster is to ACT as a ssh server, then you don't need to (and shouldn't) route your management traffic (ssh) in the same way as the BAU traffic. If one of your cluster nodes goes down, how are you 1) going to know about this 2) fix the problem? You need the ability to connect to each node. You need to know which node is the cluster leader (which should be available from the cluster daemon on each node or the controller if using NAT on a separate device).

But leaving all that aside....

Won't ssh complain about mismatching host keys

Not if you tell ssh not to. You can do this specifically for the virtual IP by an entry in the ssh_config. And unless your script is doing some messy stuff with expect and passwords, there's no security issue. If you are doing messy stuff with expect then you can always expect host key issues and handle them.

Not if all the nodes have the same host key.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .