LinuxQuestions.org - SSH Putty "Server's host key did not match the signature supplied"

- Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)

- - SSH Putty "Server's host key did not match the signature supplied" (https://www.linuxquestions.org/questions/linux-networking-3/ssh-putty-server%27s-host-key-did-not-match-the-signature-supplied-802828/)

SSH Putty "Server's host key did not match the signature supplied"

I have a SSH server "SSH-2.0-OpenSSH_5.1p1 Debian-6ubuntu2" running at IP 1.1.1.1

When I try to access it from another machine on the internet which is at 2.2.2.2 every thing goes fine. However when I try to do the same thing from 3.3.3.3 it does not work and Putty throws me this error "Server's host key did not match the signature supplied".

I went inside HKEY_Current_user\Software\SimonTatham\Putty\SshHostKeys and tried to remove all the known host and still the issue is existing, I am literally scratching my head as to what is going wrong.:banghead:

I Googled about this error and I saw many were having problem similar to mine however none were able to give some conclusive results so far.

have a look at the network diagram.

Have you tried running putty -cleanup from a command line ?

I did that command and it nucked all the other entried I had on my Putty, that is not a problem I can build them back up, However still I am faced with the same problem :scratch:

Sorry, you didn't mention that you had other entries. The idea was to clear all the crud out of the registry.

If that has been done and the error persists, then it's hard to say really. Unless something really has changed on the server.

Has it ever worked from this machine ?
Can you ssh to other machines ok ?

BTW, you don't need -p when you are ssh-ing to a standard ssh port.

Can you check what the host key is on the other machine and compare it to what is on the problem machine ?

Are you using password based login or key based ?

I don't mind about the other entries which got erased.

I have changed nothing on my server.

It had never worked from the IP 3.3.3.3 to 1.1.1.1

Currently I don't have access to 2.2.2.2 to test and see if it is working correctly, I will do that and post soon.

My SSH server is listening on Port number 21 so I have to use -p option if not Connection will be refused.

I had even tried exporting the Reg key from the working machine to the machine which does not work, and yet it is giving the same result.

I tried again to SSH from 2.2.2.2 to 1.1.1.1 and it works like a Charm.

I use password based login. I don't know how to make passwordless login using Putty, I know to do that between two Linux boxes.

I got a linux box installed in the same subnet of 2.2.2.0 and tried ssh to my 1.1.1.1 box with Debug turned on still trouble.

[Linux@localhost .ssh]$ ssh -vvv bala@1.1.1.1 -p 21
OpenSSH_4.5p1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 1.1.1.1 [1.1.1.1] port 21.
debug1: Connection established.
debug1: identity file /home/smxmgr/.ssh/id_rsa type -1
debug1: identity file /home/smxmgr/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-6ubuntu2
debug1: match: OpenSSH_5.1p1 Debian-6ubuntu2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.5
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 136/256
debug2: bits set: 504/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: put_host_port: [1.1.1.1]:21
debug3: put_host_port: [1.1.1.1]:21
debug3: check_host_in_hostfile: filename /home/smxmgr/.ssh/known_hosts
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
debug3: check_host_in_hostfile: filename /home/smxmgr/.ssh/known_hosts
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
debug1: checking without port identifier
debug3: check_host_in_hostfile: filename /home/smxmgr/.ssh/known_hosts
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
debug3: check_host_in_hostfile: filename /home/smxmgr/.ssh/known_hosts
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
debug2: no key of type 0 for host [1.1.1.1]:21
debug3: check_host_in_hostfile: filename /home/smxmgr/.ssh/known_hosts2
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts2
debug3: check_host_in_hostfile: filename /home/smxmgr/.ssh/known_hosts
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
debug2: no key of type 2 for host [1.1.1.1]:21
The authenticity of host '[1.1.1.1]:21 ([1.1.1.1]:21)' can't be established.
RSA key fingerprint is 0d:f1:e5:3a:c7:3f:35:8a:f7:69:05:96:68:d1:e3:16.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[1.1.1.1]:21' (RSA) to the list of known hosts.
debug2: bits set: 504/1024
RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01
debug1: ssh_rsa_verify: signature incorrect
key_verify failed for server_host_key
[Linux@localhost .ssh]$

EDIT

When you open putty can you go to the section in the setup category that says Bugs
and change anything with SSH2 in the description to ON, instead of auto.

Then try connecting again.
#######################################

otherwise -

Have you got physical access to the server 1.1.1.1 ?

If so can you verify the ssh server version :

Code:

ssh -v

It appears that this is a bug where the server is encrypting it's host key incorrectly and so the client can't decrypt it.

From what I've read, you could just keep on trying until it works, or you could try creating a new host key on the ssh server, as root :

Code:

rm -f /etc/ssh/ssh_host_dsa_key

rm -f /etc/ssh/ssh_host_rsa_key

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

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

and clearing known hosts on the clients before connecting.

I also suggest setting the default port on the server (22) and then trying to connect with that. If only for a test.

When you open putty can you go to the section in the setup category that says Bugs and change anything with SSH2 in the description to ON, instead of auto.

Then try connecting again.

I tried your point above it is not working.

Coming to the point of SSH key regenarationm, before going into it I am 100% sure that if I SSH from 2.2.2.2 to 1.1.1.1 it works like charm, but when 3.3.3.3 tries to access 1.1.1.1 it fails.

I will soon post the SSH -v option from 1.1.1.1 box.

SSH-2.0-OpenSSH_5.1p1 Debian-6ubuntu2

bala@ubuntu:~$ ssh -v
OpenSSH_5.1p1 Debian-6ubuntu2, OpenSSL 0.9.8g 19 Oct 2007
usage: ssh [-1246AaCfgKkMNnqsTtVvXxY] [-b bind_address] [-c cipher_spec]
[-D [bind_address:]port] [-e escape_char] [-F configfile]
[-i identity_file] [-L [bind_address:]port:host:hostport]
[-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
[-R [bind_address:]port:host:hostport] [-S ctl_path]
[-w local_tun[:remote_tun]] [user@]hostname [command]
bala@ubuntu:~$

I also suggest setting the default port on the server (22) and then trying to connect with that. If only for a test.

For this I firstly edited the sshd_config file and then restart the SSH daemon. Netstat -ant showed that SSH was listening on port 22 and I was able to locally SSH to my self. But when I tried to do over the to connect over to port 22 from 3.3.3.3 to 1.1.1.1 I don't get "Connection timed out" :-(

If you are trying to connect from outside the local network then your router will need to forward the correct port.

Well you are absolutely correct Smoker, however the 2.2.2.2 ---> 1.1.1.1 connection is working perfectly fine and 2.2.2.2 is out on the internet. My 1.1.1.1 IP is directly bound to my system eth0 card, I don't have a ADSL router sitting between my system and the internet.

I should really appreciate you trying to help me :D

However my issue is still not solved, I am literally :banghead: banging my head to get this thing to work.

Quote:

Originally Posted by bala150985 (Post 3943543)

However my issue is still not solved, I am literally :banghead: banging my head to get this thing to work.

Did you find a solution? I still have the same problem.

Regards,
Hinrich

It is really a long time since I had this problem, I don't remember the work around I made for the same.

Do you have some firewalls which prevents this connection ? Can you post a network diagram of what you are accomplishing?

Quote:

Originally Posted by bala150985 (Post 4590045)

Do you have some firewalls which prevents this connection ? Can you post a network diagram of what you are accomplishing?

No, I stopped the firewall at all.

Thanks for your response. Because of this I guess the FPU is corrupt. With OpenSuSE 12.1-64bit it works, with 12.1-32bit it doesn't. I returned the computer to the dealer (warranty).

Regards
Hinrich

Had same problem because of system changes on the server end. Needed to regenerate the RSA key on the server side so that it matched the new system configuration.

This is why SSH is considered man-in-the-middle-attack safe... Something (sometimes even the ISP, sometimes without even intentioning) is messing with your packets... try temporary switching the server to port 80 (or, if that's busy, 8080) and retry connecting with putty from 3.3.3.3 on that port...

//LE: Try what ronmuzzi said first...

I had the same problem in OpenStack environment and after banging the head and a lot of analysis, my solution was to change default hypervisor from QEMU to KVM.

Make sense what was said by hinrichd and Smokey_justme, because must there is some reason where some operation system not happen (ex: CirrOS) and others happen, like Centos7_x86_64.

I have hopefully contributed to future problems.