ssh docs rarely mention this, but for ssh to work right, you have to pay attention to the host key. alot of isps, hosting providers etc dont seem to get this.
if you dont have a key for a given host, (usually the first time you ssh to it) youll see something like this.
ryo-oki:~$ ssh foo.org The authenticity of host 'foo.org (1.2.3.4)' can't be established. RSA key fingerprint is 18:c9:13:c9:09:e4:f8:cd:88:ac:92:ef:ac:f8:4b:f3. Are you sure you want to continue connecting (yes/no)?if your on the host (preferably the console), heres how to get those fingerprints
ssh-keygen -l -f /etc/ssh/ssh_host_key.pub ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key.pubyou can also check the fingerprints for the host keys you already have.
ssh-keygen -l -f ~/.ssh/known_hostsif the fingerprint you have doesnt match the one your going to, somethings wrong. see below.
ssh uses public key cryptography like pgp and ssl, so you need to verify the hosts public key. in the initial connection, when the client requests the hosts public key, another host or router in between (or possibly just another host on the same network) can be the monkey in the middle. grossly simplified, it looks like this,
client - whats your key? -----> router -- whats your key? --> server client <-server key 00FF00----- router <--server key FF00FF-- server client <-00FF00(login:)-------- router <--FF00FF(login:)----- server client --00FF00(jdoe)---------> router ---FF00FF(jdoe)------> server client <-00FF00(password:)----- router <--FF00FF(password:)-- server client --00FF00(fluffy)-------> router ---FF00FF(fluffy)----> server
the client sends an ssh request to the server and the server responds with its public key. since this client, by definition, could be anyone, any router in the middle can accept the incomming transmission, and make its own connection to the server, pretending to be the client by spoofing its ip address. at the same time, it feeds the client its own public key. since the client doesnt already have one, it believes that this really is the servers key and sends its authentication info, which it happily encrypted with the routers public key. so the router decrypts it, now knows the clients auth info, and can thus encrypt it for the real server and send it along. since the router also initiated its fake ssh session, the server is encrypting the traffic for the router , thinking its the client, which the router just decryptes and re encrypts it for the the client pretending to be the server.
if you have the real hosts public key, the above cant work, since ssh will notice the differnt key and tell you about it. if the key really was just changed, hopefully whoever did that would have the sense to warn you, and have a safe way to get you the new one or at least its fingerprint.
on the client end, ssh keeps the host keys in ~/.ssh/known_hosts. on the server side, its kept in /etc/ssh/ssh_host_*.pub, (host_key,host_rsa_key, and host_dsa_key)
the host key on the host. (real ones are much longer) ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAvbsnbtAFo5= root@example the host key in your known_hosts file. 1.2.3.4 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAv=
the difference is just that on the host, it has that email at the end, and in your known_hosts, it doesnt, but it does have an ip address (and maybe a hostname) in front of it, the man pages for ssh and sshd have more detail. if you can get the key from the host another way (like sneakernet) you can just add it yourself.