1

Im trying to bring up gitlab environment with load balance setup... Problem i have is if a user ssh to LB using putty or git bash they get below error.

Server's host key doest not match the one PuTTY has cached in the registry

I tried adding follwing config but didn't help, Putty website clearly says Putty will never let you bypass without manual intervention.

   StrictHostKeyChecking no
    UserKnownHostsFile /dev/null    

Only option left after reading quite a number of forum is to make the ssh key same on all the server.

Will this cause any other issues?

On issue i see is if one machine is compromised and the attacker could get into other servers, Since this is in Intranet will it be a concern ?

3

"Only option left after reading quite a number of forum is to make the ssh key same on all the server. "

I think there is another option : you can use ssh certificates.

SSH actually has the functionality to use a certificate authority to authenticate servers and clients. This works both ways. Using this system, you can authenticate a host to a client, avoiding confusing messages about being unable to validate the authenticity of the host. You can also validate the client to the host, allowing you to register a new SSH key in one place and allow access across your organization.

https://www.digitalocean.com/community/tutorials/how-to-create-an-ssh-ca-to-validate-hosts-and-clients-with-ubuntu

  • While theoretically this is the best option, clients are required to manually configure their known_hosts file, which is something not many will be able or willing to do; let alone those using other clients than OpenSSH (PuTTY? Some Android app with git-over-ssh access?) – jplitza Feb 7 '17 at 10:28
  • yes, clients will have to manually add one line to their known_hosts file. But I think in OP's case, it worths the work. – bgtvfr Feb 7 '17 at 13:23
1

Sharing the host key shouldn't be a problem.

SSH usually uses Diffie-Hellman key exchange (which you can even enforce by setting KexAlgorithms in your sshd_config), meaning that even if an attacker is in possession of the private host key, he cannot passively decrypt connections to other servers with the same host key. In this scenario, the host key really is only used for the authenticity check of the server.

Also, even if an attacker that owned one of your servers was able to intrude your other servers (which he probably is anyway, in the same way he got into the first one), what would be his gain? Being load balancers, the servers probably all have equal permissions and access to the intranet, so having control over one of them is good enough for an attacker, I wouldn't see an advantage in having control over all of them.

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.