Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
add comment

2 Answers

up vote 14 down vote accepted
+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
share|improve this answer
    
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. –  ℝaphink 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. –  Michael Lowman 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
show 7 more comments

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

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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