Google Gruppi non supporta più i nuovi post o le nuove iscrizioni Usenet. I contenuti storici continuano a essere visibili.

PuTTY failing "Server's host key did not match the signature supplied" suddenly

3.185 visualizzazioni
Passa al primo messaggio da leggere

Raymond

da leggere,
9 mar 2008, 21:03:5709/03/08
a
Dear All,

PuTTY suddenly fails to connect to my server reporting "Server's host
key did not match the signature supplied".

Configuration as follows:

PuTTY Version: Release 0.60

Server: CentOS release 5 (Final) with openssh-server-4.3p2-24.el5
openssh-4.3p2-24.el5

Tried connecting with ssh client and ssh reports:
"hash mismatch
key_verify failed for server_host_key"

or

"RSA_public_decrypt failed: error:0407006A:rsa
routines:RSA_padding_check_PKCS1_type_1:block type is not 01
key_verify failed for server_host_key"

Have anyone encountered this problem before?

Connection to other server is ok.

Regards,

Raymond Pau

Todd H.

da leggere,
9 mar 2008, 21:13:5509/03/08
a
Raymond <rpa...@gmail.com> writes:

When did you create the profile? Did the server's key perhaps simply
change from then until now?

Be sure to verify the new server signature with an admin or user of
that box to verify that you aren't being MITM'd.

ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key.pub

Is the command for a user on the machine to list out the
fingerprints.


--
Todd H.
http://www.toddh.net/

Raymond

da leggere,
10 mar 2008, 20:48:1010/03/08
a

Ok, this is what I get:

# ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
2048 4b:22:b7:31:73:66:64:07:c5:2d:51:3e:69:82:9e:53 /etc/ssh/
ssh_host_rsa_key.pub
# ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key.pub
1024 fb:23:96:4f:96:fa:ca:3a:d1:a2:d3:69:96:a0:7c:1e /etc/ssh/
ssh_host_dsa_key.pub

switch to a normal user:
$ ssh mydomainname.com
The authenticity of host 'mydomainname.com (00.000.000.000)' can't be
established.
RSA key fingerprint is 4b:22:b7:31:73:66:64:07:c5:2d:51:3e:69:82:9e:
53.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'mydomainname.com,00.000.000.000' (RSA) to
the list of known hosts.


hash mismatch
key_verify failed for server_host_key

$ ssh localhost
The authenticity of host 'localhost (127.0.0.1)' can't be established.
RSA key fingerprint is 4b:22:b7:31:73:66:64:07:c5:2d:51:3e:69:82:9e:
53.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'localhost' (RSA) to the list of known
hosts.


hash mismatch
key_verify failed for server_host_key

The strange thing is, if I tried hard enough, retrying the connection
repeatedly, it will sometimes get connected.
Both openssh client and PuTTY exhibit the same problem. I would think
that the problem lies with openssh server then.

How do I troubleshoot this kind of problem? Any logs that I can watch?

Regards,

Raymond Pau

Todd H.

da leggere,
10 mar 2008, 21:44:2110/03/08
a
Raymond <rpa...@gmail.com> writes:

> Ok, this is what I get:
>
> # ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
> 2048 4b:22:b7:31:73:66:64:07:c5:2d:51:3e:69:82:9e:53 /etc/ssh/
> ssh_host_rsa_key.pub
> # ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key.pub
> 1024 fb:23:96:4f:96:fa:ca:3a:d1:a2:d3:69:96:a0:7c:1e /etc/ssh/
> ssh_host_dsa_key.pub

Don't need to be root to do these typically, fwiw. What machine did
you run this on?

> switch to a normal user:
> $ ssh mydomainname.com
> The authenticity of host 'mydomainname.com (00.000.000.000)' can't be
> established.
> RSA key fingerprint is 4b:22:b7:31:73:66:64:07:c5:2d:51:3e:69:82:9e:
> 53.
> Are you sure you want to continue connecting (yes/no)? yes
> Warning: Permanently added 'mydomainname.com,00.000.000.000' (RSA) to
> the list of known hosts.
> hash mismatch
> key_verify failed for server_host_key


Okay. Redo that with the -v switch and post here. -v is for
verbose and will tell you far more detail as to where exactly it's
failing.

And where was this done from?

> $ ssh localhost
> The authenticity of host 'localhost (127.0.0.1)' can't be established.
> RSA key fingerprint is 4b:22:b7:31:73:66:64:07:c5:2d:51:3e:69:82:9e:
> 53.
> Are you sure you want to continue connecting (yes/no)? yes
> Warning: Permanently added 'localhost' (RSA) to the list of known
> hosts.
> hash mismatch
> key_verify failed for server_host_key

Was this done from the perspective of your domain?


> The strange thing is, if I tried hard enough, retrying the connection
> repeatedly, it will sometimes get connected.
> Both openssh client and PuTTY exhibit the same problem. I would think
> that the problem lies with openssh server then.

Any load balancing going on that you might not be aware of?

> How do I troubleshoot this kind of problem? Any logs that I can
> watch?

/var/log/messages perhaps, depending on the logging level
Wherever /etc/syslog.conf points all stuff to.

Raymond

da leggere,
10 mar 2008, 23:10:5310/03/08
a
On Mar 11, 9:44 am, comph...@toddh.net (Todd H.) wrote:
> Raymond <rpa...@gmail.com> writes:
> > Ok, this is what I get:
>
> > # ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
> > 2048 4b:22:b7:31:73:66:64:07:c5:2d:51:3e:69:82:9e:53 /etc/ssh/
> > ssh_host_rsa_key.pub
> > # ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key.pub
> > 1024 fb:23:96:4f:96:fa:ca:3a:d1:a2:d3:69:96:a0:7c:1e /etc/ssh/
> > ssh_host_dsa_key.pub
>
> Don't need to be root to do these typically, fwiw.   What machine did
> you run this on?  
>

On the server console itself.

> > switch to a normal user:
> > $ ssh mydomainname.com
> > The authenticity of host 'mydomainname.com (00.000.000.000)' can't be
> > established.
> > RSA key fingerprint is 4b:22:b7:31:73:66:64:07:c5:2d:51:3e:69:82:9e:
> > 53.
> > Are you sure you want to continue connecting (yes/no)? yes
> > Warning: Permanently added 'mydomainname.com,00.000.000.000' (RSA) to
> > the list of known hosts.
> > hash mismatch
> > key_verify failed for server_host_key
>
> Okay.   Redo that with  the -v switch    and post here.   -v  is for
> verbose and will tell you far more detail as to where exactly it's
> failing.
>
> And where was this done from?
>

On the same server itself too. I had replaced the actual domain name
and IP Address with the dummy "mydomainname.com" for privacy.

This is what I get with the -v flag:

$ ssh -v localhost
OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/xxxx/.ssh/identity type -1
debug1: identity file /home/xxxx/.ssh/id_rsa type 1
debug1: identity file /home/xxxx/.ssh/id_dsa type -1
debug1: loaded 3 keys
debug1: Remote protocol version 2.0, remote software version
OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
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
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'localhost' is known and matches the RSA host key.
debug1: Found key in /home/xxxx/.ssh/known_hosts:2
hash mismatch
debug1: ssh_rsa_verify: signature incorrect
key_verify failed for server_host_key


$ ssh -v localhost
OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/xxxx/.ssh/identity type -1
debug1: identity file /home/xxxx/.ssh/id_rsa type 1
debug1: identity file /home/xxxx/.ssh/id_dsa type -1
debug1: loaded 3 keys
debug1: Remote protocol version 2.0, remote software version
OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
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
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'localhost' is known and matches the RSA host key.
debug1: Found key in /home/xxxx/.ssh/known_hosts:2


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

I had replace the actual username with "xxxx" for privacy.

> > $ ssh localhost
> > The authenticity of host 'localhost (127.0.0.1)' can't be established.
> > RSA key fingerprint is 4b:22:b7:31:73:66:64:07:c5:2d:51:3e:69:82:9e:
> > 53.
> > Are you sure you want to continue connecting (yes/no)? yes
> > Warning: Permanently added 'localhost' (RSA) to the list of known
> > hosts.
> > hash mismatch
> > key_verify failed for server_host_key
>
> Was this done from the perspective of your domain?
>
> > The strange thing is, if I tried hard enough, retrying the connection
> > repeatedly, it will sometimes get connected.
> > Both openssh client and PuTTY exhibit the same problem. I would think
> > that the problem lies with openssh server then.
>
> Any load balancing going on that you might not be aware of?  

Nope. No load balancing, only 1 server.

Todd H.

da leggere,
10 mar 2008, 23:51:1210/03/08
a
Raymond <rpa...@gmail.com> writes:


Okay... that helps. Seems in your known_hosts file, there's a
cached value of the server's key that doesn't match what your server
is sending. Edit that file and get rid of it.

But... I don't imagine that'll be the end of the story because you
showed us earlier times when it was being added to the file and there
were still problems.

Same deal here... lop out the localhost entry and try again.

If this doesnt' fix it, I'd look up the docs to generate new RSA and DSA
keys on the server end and regenerate those and see if it can be
brought to happiness.

Perhaps others with more admin experience could lend other insight.
Normally I'd sit these questions out, but hopefully I get ya pointed
in the right direction.

Raymond

da leggere,
11 mar 2008, 01:27:1011/03/08
a
> Todd H.http://www.toddh.net/- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

Regenerating new RSA and DSA keys for the server didn't help.
Removing .ssh/known_hosts and re-adding the server keys again didn't
help either.

Any other suggestions will be greatly appreciated.

Thank you.

Per Hedeland

da leggere,
11 mar 2008, 18:04:4011/03/08
a
In article
<fd9048c1-a1be-4bec...@s13g2000prd.googlegroups.com>

It seems that the server's public and private keys don't match up -
i.e. it sends the public key, and then the signature it produces by
using its private key can not be verified with that public key, because
they're not a "pair". In which case your suggestion to re-generate the
keys should take care of it (though some investigation into how this
situation arose might be appropriate for someone with even minimal
paranoia...).

>Regenerating new RSA and DSA keys for the server didn't help.
>Removing .ssh/known_hosts and re-adding the server keys again didn't
>help either.

Which would seem to refute that theory - except... - if you aren't
actually looking for (and generating) the keys in the same place that
the server is looking for them. Are you 100% sure that the server you
are currently running (which may or may not be using
/etc/ssh/sshd_config) looks for /etc/ssh/ssh_host_[rd]sa_key*? A quick
first check: Did the public key fingerprint, as reported by the client,
change when you had re-generated the keys?

>Any other suggestions will be greatly appreciated.

Well, maybe a long shot, but I tried...:-)

--Per Hedeland
p...@hedeland.org

Nico Kadel-Garcia

da leggere,
11 mar 2008, 19:04:4511/03/08
a
On 11 Mar, 22:04, p...@hedeland.org (Per Hedeland) wrote:
> In article
> <fd9048c1-a1be-4bec-85dd-a432293b1...@s13g2000prd.googlegroups.com>
> p...@hedeland.org- Hide quoted text -

>
> - Show quoted text -

Hmmmm. I wonder if our faithful poster has a root-kitted box with
someone else's SSH server installed on it? Or has a network setup that
is passing along the SSH connection to an unexpected server, such as a
NAT setup?

0 nuovi messaggi