9

We have 2 production servers on a VIP, only one is in use at a time, for example:

myservice.mycompany.uk normally points to server1, in the event that server1 fails it is changes to point at server2.

There are some other servers which need to send files to myservice.mycompany.uk via SFTP and it should be totally transparent to them if we failover to server2.

The problem is that while the keys are installed on both server1 and server2, the other servers will have host key verification issues, because the host key of server2 is different to the host key of server1. This causes a security error (since strict checking is on), and a line must be removed from known_hosts to make it work.

Our IT guy has suggested that we can create 2 entries in known_hosts, one with the key for server1 and one with server2, both with the host myservice.mycompany.uk.

Is that likely to work? How can this be done with putty/psftp on windows? Since the host key is stored in the registry and duplicate names are not allowed. Is there a better way, can we for example, force the servers to have the same host key?

17
+50

To make it easier for the clients, I would just use the same host key on both machines. Just copy one of the keys (the one of the server currently in use) to the second machine. They keys are in /etc/ssh/ssh_host_*.

Another option is to deactivate host key checking on clients. This can be done by tuning their ssh_config to use:

Host myservice.mycompany.uk
    StrictHostKeyChecking
12
  • Turning off the host key checking rather undermines the point of using SSH to transfer these files, duplicating the host key is probably the best solution.
    – James Yale
    Jul 22 '11 at 12:18
  • 1
    Turning off host key checking doesn't mean the communication is not properly encrypted, which is the main point of SSH. That said, as I said, I favor the first solution myself.
    – raphink
    Jul 22 '11 at 12:27
  • In the client-version (with different server keys) of the solution you also need to add UserKnownHostsFile=/dev/null else the first key will go into the known-hosts and the second will lead to a "man in the middle" warning.
    – Nils
    Jul 22 '11 at 20:45
  • @Nils this isn't necessary; setting StrictHostKeyChecking yes will make the UserKnownHosts file ignored in favor of the system known hosts file. So anything that modifies the UserKnownHosts is rather pointless. Jul 22 '11 at 20:55
  • Ok - I have to clarify this further: I speak about the case where you have two different server-keys. There you have to specify StrictHostKeyChecking no and additionally set the UserKnownHostsFile to /dev/null. In that case all host keys will be accepted (rendering this security level useless, of course).
    – Nils
    Jul 25 '11 at 20:45
0

I archived this in this way, user root run one script at 23:00 PM that connect to logical ip address of linux cluster, so in case of failover of the ip address my ssh fingerprint change

echo "StrictHostKeyChecking no" >> /root/.ssh/config 
echo "UserKnownHostsFile /dev/null" >> /root/.ssh/config

In this way, the setting is for root only

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.