SSH known_hosts Cheat Sheet
Posted by Planet Malaysia on June 9, 2008
Secure Shell or SSH is a network protocol that allows data to be exchanged using a secure channel between two computers. SSH uses public-key cryptography to authenticate the remote computer and allow the remote computer to authenticate the user.
In order to use public-key secure connection with other Linux hosts (ssh, scp, sftp) there is a special directory, ~/.ssh/, where passphrases and public keys are stored. Normally you wouldn’t need to know the gory details, but from time to time a host will change its public key and then you have difficulty using ssh, sftp or scp with that host, and have to edit a file named known_hosts.
If you try to ssh to another computer, but get an error message that warns about a changed or incorrect public key, then it is probably just a case of that host changing its public key. (It is possible, though usually not the case, that malicious hacking is involved.) Unless you actually suspect hacker involvement, you can edit the file ~/.ssh/known_hosts using your usual text editor (vi, emacs, or pico) and delete any line with the name or IP address of that host. Then when you try to ssh that host again, it will be like the first time ever; ssh will ask you if you want to accept a new public key, you type the whole word yes, and everything will proceed normally from there.
Said for an example, I have a Linux cluster running on 2 machines(active/passive mode) and usually users are connect using a virtual hostname or virtual IP address. Whenever Linux cluster or heartbeat switches over to the second machine and you try to ssh to it, ssh will reply with a WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! Annoying right?
So?
How to ignore SSH known_hosts in these case?
How to make SSH known_hosts work for cluster environments?
SSH known_hosts cheat sheet
Imagine you have the 2 cluster machines node1 and node2 with virtual hostname running as below:
node1 – IP address: 192.168.1.1
node2 – IP address: 192.168.1.2
virtual hostname or clustername/virtual IP address
vnode – IP address: 192.168.1.100
I’m assume you know how to generate DSA or RSA key using ssh-keygen command.
Option 1:
- ssh node1 and type yes if required
- ssh node2 and type yes if required
- edit ~/.ssh/known_hosts
- modify known_hosts and add vnode and IP address as example below:
- node1,vnode,192.168.1.1,192.168.1.100 ssh-rsa AAAAB32Nsomething[...]
- node2,vnode,192.168.1.2,192.168.1.100 ssh-rsa AAAAB32Nsomethingelse[...]
Option 2:
- SSH to node1
- Copy SSH DSA and RSA key from node1 to node2
ssh_host_dsa_key
ssh_host_dsa_key.pub
ssh_host_rsa_key
ssh_host_rsa_key.pub
scp /etc/ssh/ssh_host_dsa_key* node2:/etc/ssh/.
scp /etc/ssh/ssh_host_rsa_key* node2:/etc/ssh/.
/etc/init.d/sshd restart for node2
I’m sure you will happy if you have a script and cronjob that require SSH, SCP or SFTP to virtual hostname or IP address. No matter you SSH, SCP or SFTP on which cluster machine using virtual hostname or virtual IP address.
Note: please do understand more about SSH security before implement this.
Enjoy!
Possibly Related Posts:
- How to add Dell PERC Drivers into VMware Converter Cold Clone ISO
- Top 10 Free Anti Virus
- How to Install Webmin on OpenFiler
- Microsoft SQL 2008 Agent not starts
- VMware Workstation 7 Serial Key
Comments
4 Responses to “SSH known_hosts Cheat Sheet”
Leave a Reply
Hi there, I was looking around for a while searching for cryptography and network security and I happened upon this site and your post regarding SSH known_hosts Cheat Sheet, I will definitely this to my cryptography and network security bookmarks!
IP Address Reference Guide Cheat Sheet
http://www.ip2location.com/ip-address-quick-reference-guide.aspx
I have to say, SSH was the best thing they ever came out with. You can’t beat its security nor its reliabilty.
Thanks. For a moment, I thought this (passwordless sshing to a logical hostname) was just not possible and the solution that we were working on might flop!
Thanks once again.