CODEWITHSUNDEEP
sshverificationopenssh
hornetbzz
hornetbzz

Reputation: 9357

ssh host key verification failed on one of the clients only

I can't ssh from client "A" to server "B" (but I can from many other ssh clients on the same subnet than "A" - all are *nux machines)

serverA>ssh -v -p PORT user@serverB 

OpenSSH_5.3p1 Debian-3ubuntu5, OpenSSL 0.9.8k 25 Mar 2009  
debug1: Reading configuration data /etc/ssh/ssh_config  
debug1: Applying options for *  
debug1: Connecting to serverB [serverB] port PORT.  
debug1: Connection established.  
debug1: identity file /home/user_A/.ssh/id_rsa type -1  
debug1: identity file /home/user_A/.ssh/id_dsa type 2  
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024  
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024  
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5  
debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*  
debug1: Enabling compatibility mode for protocol 2.0  
debug1: Local version string SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu5  
debug1: SSH2_MSG_KEXINIT sent  
debug1: SSH2_MSG_KEXINIT received  
debug1: kex: server->client aes128-ctr hmac-md5 none  
debug1: kex: client->server aes128-ctr hmac-md5 none  
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent  
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP  
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent  
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY  
debug1: checking without port identifier  
Host key verification failed.

I've already checked these following pts on client A - as server A looks to be the point - :

I've tried :

So I'm really stacked now ! ssh specialists welcome home.

Thx in advance

Upvotes: 1

Views: 12812

Answers (3)

user3064538
user3064538

Reputation:

For future reference I fixed what I think was the same issue by doing (from the client)

$ ssh-keyscan [HOST-SERVER-IP]
# [HOST-SERVER-IP] SSH-2.0-OpenSSH_6.7
[HOST-SERVER-IP] ssh-rsa AAAAB3NzaC1yc2EAAAADA ... etc ... +Zl
# [HOST-SERVER-IP] SSH-2.0-OpenSSH_6.7
[HOST-SERVER-IP] ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTI ... etc ... +1w=

I then removed everything in ~/.ssh/known_hosts and copy pasted the two keys exactly the way they appeared into ~/.ssh/known_hosts.

I actually copy pasted the ssh-rsa one only at first, because I thought that's what I was using. For some reason that didn't work, when I copy pasted the second key in it worked like a charm. Of note as well that I enabled PasswordAuthentication in my sshd config on the server so as to not worry about keys.

Upvotes: 0

Mark Lakata
Mark Lakata

Reputation: 20838

I had the same problem, on an embedded system that I have no control over. I think the way I fixed it was to install all of the public keys on both sides, manually.

The problem started with ssh complaining that 'ssh-askpass' wasn't found. The work around for this was to unset the $DISPLAY environment variable (yes, totally obvious). I read somewhere that OpenSSH will try to use ssh-askpass if DISPLAY is set. So I did this

unset DISPLAY

Then I basically got the error message in the OP. So, continuing on, I did everything on this page to create and copy the public key from A to B.

http://knol.google.com/k/how-to-use-ssh-keygen#

I created both an RSA key and DSA key. I guess RSA is older and DSA is newer. (It looks like it was using the RSA key.) Anyways, this didn't solve the problem alone.

Then I tried copying server "B" public key back to client "A"'s known_hosts. And that worked!

From server B, grab

/etc/ssh/ssh_host_rsa_key.pub

Then add the contents of that to 

~/.ssh/known_hosts

on client "A", with the IP address of server "B" prepended to the beginning (and one space)

192.168.0.200 ssh-rsa QbJfEdeu4rsgeAAAAAB3Nza.... etc ... ==

A useful debugging tip is to use the -vvv option to ssh to get super verbose output.

Upvotes: 0

hornetbzz
hornetbzz

Reputation: 9357

Don't understand what exactly I did wrong for this particular server.. What remains "strange" is that destroying "known_hosts" on the client side did not drive to the expected positive effect.

Anyway pls find hereafter what I did manually, quite ugly but works:
Note: This assumes full access to both machines (client and server)

server side : regenerate the 2 pairs of keys (rsa and dsa) 

ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key  
ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key

client side:
generate a pair of dsa keys (private and public) for the user "foo" 

ssh-keygen -t dsa -f /home/foo/.ssh/my_client_key

add this new key to the ssh-agent if running 

ssh-add /home/foo/.ssh/my_client_key

add the content of the server ssh_host_rsa_key.pub to the client /home/foo/.ssh/known_hosts, after the IP/port: 

[server_ip]:server_port copy/paste here the server public rsa key (ctrl+shift+C/V)  
[server_ip]:server_port copy/paste here the server public dsa key (ctrl+shift+C/V)

now back to the server side :

copy/paste the client public key /home/foo/.ssh/my_client_key.pub into /home/bar/.ssh/.authorized_keys in order to allow connection to the user "foo" to connect to "bar" account:

make sure of the path consistency with /etc/ssh/sshd_config to be able tu use the file .authorized_keys : 

AuthorizedKeysFile      %h/.ssh/.authorized_keys

restart the ssh server 

/etc/init.d/ssh restart

client: now the client "foo" can ssh to the user "bar" on the server :

foo@client>$ ssh -p PORT bar@server_ip

Note: in my case, both client and server are running locally within VM's. Do not use these settings for production obviously.

EDIT: Reading a bit more carefully the man ssh pages, it should be possible to get around this in a much proper manner, ref to the man: "The StrictHostKeyChecking option can be used to control logins to machines whose host key is not known or has changed."

Upvotes: 3

Related Questions