Problems with ssh

[drinagd]

Hi,

We use OpenSSH for one of our applications, we have two servers configured for this but we only let the users connect to one of them, in case this server fails, we just change the hostname and IP address of the other server and let it take over the access to the external storage, so it is transparent for the users which server they are accessing to. At least, that’s the idea, but now we are facing some serious trouble, our main server is useless, so the secondary server is active, but now, if we try to access via ssh we get a message “REMOTE HOST IDENTIFICATION HAS CHANGED”, this is easily solved if we delete the “known_hosts” file in every client machine that will access the server. The problem is that we have hundreds of users that are external to our organization and non-technology savvy, so this poses a huge problem, is there a way that we can do something on the server side, so that all users can access without having to change anything on the client side?

Thanks in advance for your help.

Best regards,

Drina

 

[khalidaaa]

What type of clients do you have? are they windows or Unix?

well, i don't know why there should be a problem for now as you were doing this before with no problems!


when you switch the main and the secondary before, did you have any problems like that?

I'm not sure if i understood the case clearly!

 

[drinagd]

Hi,

Clients are windows. It's been a while since we needed to switch servers, I don't recall having any problems before, what we are doing rightn now is preparing a guide for the users to have them delete the control file on their side, but we discovered that this problem only happens with users that use "NetTerm".

regards,

Drina

 

[khalidaaa]

hmmm

I have not used NetTerm but logically speaking if you were able to connect previously using the secondary server then you should do it now without even going and changing the clients settings!

what is included exactly in the known_hosts file? Is it the machine MAC address? coz refering to what you said just now that you are changing the name and the IP of the secondary server as of the main server, right?

Then if the clients are using just the IP and the name of the server, It should connect to the server (providing that the clients are not using NetBIOS names for resolution) and even if they use that, the records on the clients should expire after a while and a new reference (with the correct cridentials) should be updated in the arp cache!

I beleive NetTerm is using that special file you mentioned (known_hosts) when connecting to your server so if that file doesn't include the server's MAC address i don't see why it doesn't connect any why?

Regards
Khalid

 

[plamb]

known_hosts file nis part of ssh. gets created with and encrypted handshaking ID using random number generater this normal.

 

[khalidaaa]

ok, so is there a way to copy the main server key into the secondary server and keep this known_hosts file in the clients machine?

(I still don't know how this was working previously and not now?!?)

 

[jstacey]

What I have done for a similar setup is my secondary machine (in a colocate facility across town) has the same ssh host keys as my main production server.

/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_dsa_key

We have never had to actually use the secondary in a DR situation but it worked well in our testing phase.

HTH

 

[ogniemi]

you need to have both server's host keys the same (I do this on all a cluster nodes) - just copy from one node to the other keys /usr/local/etc/ssh_h* files - after that sshd restart is required. You should also remove "known_hosts" files in the system rid off errors.


you can also prepare global known host file in /usr/local/etc/ssh_known_hosts storing in it known hosts keys - it is not needed but it allows avoid promt for known host key accepting

there is also:
StrictHostKeyChecking no

in ssh_config file which does:
The option StrictHostKeyChecking specifies whether or not ssh will automatically add new host keys to the $HOME/.ssh/known_hosts file, or never automatically add new host keys to the host file. This option, when set to yes, provides maximum protection against Trojan horse attacks. One interesting procedure with this option is to set it to no at the beginning, allow ssh to add automatically all common hosts to the host file as they are connected to, and then return to set it to yes to take advantage of this feature.