SSH Putty "Server's host key did not match the signature supplied"
1 Attachment(s)
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 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 |
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:
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:
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. |
All times are GMT -5. The time now is 12:14 AM. |