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?

Nils
  • 7,657
  • 3
  • 31
  • 71
Paul Creasey
  • 93
  • 1
  • 1
  • 7

2 Answers2

17

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
raphink
  • 11,337
  • 6
  • 36
  • 47
  • 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. – 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
  • @Nils: I (and @Michael, too I believe) speak about the case where you have two different server keys, too. The fact of specifying `StrictHostKeyChecking no` renders `UserKnownHostsFile` useless, whether you have a single shared key, or two keys. – raphink Jul 26 '11 at 07:50
  • @Raphink: Actually, turning off host key checking *does* mean that the communication isn't properly encrypted, as without the ability to authenticate the remote, a MitM attack is trivial and you effectively don't have useful encryption any more. – womble Jul 27 '11 at 23:38
  • Turning off host key checking opens you up to man-in-the-middle attacks. I'd advise against it. – Paweł Brodacki Jul 28 '11 at 16:31
  • @Raphink: I rechecked yesterday with CentOS 5. My comment from Jul 22 is valid (man in the middle warning will prevent ssh-connection after the IP failed over). Where is yours valid? – Nils Jul 29 '11 at 21:12
  • @Pawel: Turning off hostkeychecking will not turn off encryption. But you will not be sure that is is the "right" host you connect to. - But if it does not accept your private user key with a matching public key... (you are propably right if you use PW-authentication with ssh) – Nils Jul 29 '11 at 21:17
  • @Nils The sshd on the attacker's host may be modified to allow you login with any key, and then pass the data you transmit to the server you intend to login to. If the attacker has access to the destination server (a legitimate or a cracked account), he can mount mitm attack. If not, diffie-hellman-group1-sha1 key exchange protects you. Still, I do not like the idea. If you failover a server, failover the keys as well. – Paweł Brodacki Jul 30 '11 at 05:34
  • Failover of the keys is an interesting approach. I don`t like having the same private keys on many servers, too - but how do you failover keys from a "down" server? In that case you can use the same keys on your whole cluster right from the start (else they have to be available anyway anyhow on the other nodes)- – Nils Jul 30 '11 at 19:10
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

c4f4t0r
  • 5,149
  • 3
  • 28
  • 41