# ssh: "key_verify failed"

## nitro322

I keep getting this error when trying to connect to a remote ssh server :

```
key_verify failed for server_host_key
```

If I use the -v parameter, I get this:

```
OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090605f

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: Rhosts Authentication disabled, originating port will not be trusted.

debug1: ssh_connect: needpriv 0

debug1: Connecting to host [ip_addr] port 22.

debug1: Connection established.

debug1: identity file /home/user/.ssh/identity type -1

debug1: identity file /home/user/.ssh/id_rsa type -1

debug1: identity file /home/user/.ssh/id_dsa type -1

debug1: Remote protocol version 1.99, remote software version 3.1.0 SSH Secure Shell (non-commercial)

debug1: no match: 3.1.0 SSH Secure Shell (non-commercial)

Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_3.4p1

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: dh_gen_key: priv key bits set: 131/256

debug1: bits set: 476/1024

debug1: sending SSH2_MSG_KEXDH_INIT

debug1: expecting SSH2_MSG_KEXDH_REPLY

debug1: Host 'host' is known and matches the DSA host key.

debug1: Found key in /home/user/.ssh/known_hosts:2

debug1: bits set: 517/1024

debug1: ssh_dss_verify: signature incorrect

key_verify failed for server_host_key

debug1: Calling cleanup 0x80689e0(0x0)
```

I'm able to connect to every other ssh server from my box, and I'm able to connect to this server in particular from any other box, so I don't really know what the problem is.  Any ideas?  Thanks.

----------

## rac

Might you have a stale host key in /etc/ssh/known_hosts or ~/.ssh/known_hosts on the machine you are trying to connect from?

----------

## nitro322

I checked that.  I had this problem on my two previous installs (which I carried over my .ssh/ directory), and deleting all references to that server and hostname didn't help.  Everything relating to ssh on this current install is fresh (it even asked me if I was to accept the key or not), so there were no prior entries.  Is there any way to just force it to make a connection, or something like that?

----------

## rac

The server is not running OpenSSH, right?  It could be an incompatibility between OpenSSH and SSH.

 *nitro322 wrote:*   

> Is there any way to just force it to make a connection, or something like that?

 

Well, it's extremely ugly, but you could patch kexdh.c to nop out the call to key_verify and recompile.  I don't think I can really recommend this course of action, however.

----------

## Cid Highwind

 *nitro322 wrote:*   

> 
> 
> ```
> 
> debug1: sending SSH2_MSG_KEXDH_INIT
> ...

 

SSH is still seeing a known key for that host in line 2 of your ~/.ssh/known_hosts.  If you already deleted that and it still fails, can you post the new debug output from the next attempt at connecting?

----------

## klieber

You created a new key as part of the new install on the client machine, correct? And I'm guessing that new key has the same username and/or hostname as your old machine.

If so, you probably need to delete that entry from /home/user/.ssh/authorized_keys2 on the server.  It is expecting a different signature than the one you are presenting.

--kurt

----------

## Naan Yaar

FWIW, I have had the exact same problem when trying to connect from my gentoo box to a redhat 6.x box using ssh.  I have googled for some seemingly good pointers -- changing Ciphers in /etc/ssh_config, reducing the optimization level, etc..  None worked.   I can connect to the same machine from another redhat box and Putty on a Windows machine, so I suspect it is an incompatibility issue between Gentoo's openssh and that on the ssh server.

----------

## klieber

 *Naan Yaar wrote:*   

> I can connect to the same machine from another redhat box and Putty on a Windows machine, so I suspect it is an incompatibility issue between Gentoo's openssh and that on the ssh server.

 

Do you only have the problem when using keys or does it happen with regular password authentication as well?

--kurt

----------

## Naan Yaar

Happens with both keys and password authentication.

 *klieber wrote:*   

> ...
> 
> Do you only have the problem when using keys or does it happen with regular password authentication as well?
> 
> --kurt

 

----------

## klieber

 *Naan Yaar wrote:*   

> Happens with both keys and password authentication.

 

Definitely odd.  If you post the output of ssh -v -v <server name> perhaps someone else here will recognize the problem.

OpenSSH *should be* OpenSSH, so it's certainly puzzling that you wouldn't be able to connect to one OpenSSH box from another.

Also, what are the OpenSSH version numbers of the client and the server?

--kurt

----------

## Naan Yaar

Gentoo: OpenSSH_3.4p1

Remote: OpenSSH 3.1.0

Could be a problem with host keys that are dss rather than rsa...

```

OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090605f

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: Rhosts Authentication disabled, originating port will not be trusted.

debug1: ssh_connect: needpriv 0

debug1: Connecting to xxx.xxx.xxx [###.###.###.###] port 22.

debug1: Connection established.

debug1: identity file /home/xxxxx/.ssh/identity type -1

debug1: identity file /home/xxxxx/.ssh/id_rsa type -1

debug1: identity file /home/xxxxx/.ssh/id_dsa type -1

debug1: Remote protocol version 2.0, remote software version 3.1.0 SSH Secure Shell (non-commercial)

debug1: no match: 3.1.0 SSH Secure Shell (non-commercial)

Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_3.4p1

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug2: kex_parse_kexinit: diffie-hellman-group-exchange-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,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se

debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se

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

debug2: kex_parse_kexinit: none

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-group1-sha1

debug2: kex_parse_kexinit: ssh-dss

debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,twofish128-cbc,cast128-cbc,twofish-cbc,blowfish-cbc,aes192-cbc,aes256-cbc,twofish192-cbc,twofish256-cbc,arcfour

debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,twofish128-cbc,cast128-cbc,twofish-cbc,blowfish-cbc,aes192-cbc,aes256-cbc,twofish192-cbc,twofish256-cbc,arcfour

debug2: kex_parse_kexinit: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,none

debug2: kex_parse_kexinit: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,none

debug2: kex_parse_kexinit: none,zlib

debug2: kex_parse_kexinit: none,zlib

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: dh_gen_key: priv key bits set: 132/256

debug1: bits set: 534/1024

debug1: sending SSH2_MSG_KEXDH_INIT

debug1: expecting SSH2_MSG_KEXDH_REPLY

debug3: check_host_in_hostfile: filename /home/xxxxx/.ssh/known_hosts

debug3: check_host_in_hostfile: match line 2

debug3: check_host_in_hostfile: filename /home/xxxxx/.ssh/known_hosts

debug3: check_host_in_hostfile: match line 2

debug1: Host 'xxx.xxx.xxx' is known and matches the DSA host key.

debug1: Found key in /home/xxxxx/.ssh/known_hosts:2

debug1: bits set: 499/1024

debug1: ssh_dss_verify: signature incorrect

key_verify failed for server_host_key

debug1: Calling cleanup 0x80649f0(0x0)

```

----------

## klieber

Have you tried connecting using version 1 instead of version 2?  From the error output, it looks very much like the problem is on the server-side, not the client side.  My guess is it's not creating version 2 keys when sshd starts or there's some other problem with the v2 keys on the server.

Also, since you say you can connect to the same server from other boxen, try forcing version 2 on one of those machines and see if you're still able to connect.  They could be falling back to v1 authentication when your gentoo box is configured to only use v2.  (just a thought)

Finally, if you have control over the OpenSSH 3.1.0 box, you might consider upgrading that to 3.4 -- I believe 3.1 is susceptible to the ssh exploit that was released a while back, though I'm not certain.

--kurt

----------

## Naan Yaar

I have tried forcing "1".  It quits with a protocol mismatch.  The redhat box that works uses protocol 2 and does not fall back to 1.  I have compared the log outputs and the main difference is that, on the rh box, the dss key verify stage passes rather than failing.

I unfortunately do not have su access on the remote box (will probably talk to the remote system admin about version upgrade).

Thanks for the responses.

 *klieber wrote:*   

> Have you tried connecting using version 1 instead of version 2?  From the error output, it looks very much like the problem is on the server-side, not the client side.  My guess is it's not creating version 2 keys when sshd starts or there's some other problem with the v2 keys on the server.
> 
> Also, since you say you can connect to the same server from other boxen, try forcing version 2 on one of those machines and see if you're still able to connect.  They could be falling back to v1 authentication when your gentoo box is configured to only use v2.  (just a thought)
> 
> Finally, if you have control over the OpenSSH 3.1.0 box, you might consider upgrading that to 3.4 -- I believe 3.1 is susceptible to the ssh exploit that was released a while back, though I'm not certain.
> ...

 

----------

## cfactor

I agree with Naan Yaar.  I just upgraded openssh on my originally gentoo1.1a system yesterday and have been having the same problem.  I tried connecting to several servers, and the only ones I have this problem on are the machines that are using DSA hostkeys on the server.

I have ran across a posting on the web where a guy ran some sort of validation test on the dsa enc/dec method on a recent openssh, and it failed.  But I can't find the page anymore.

On the other hand, I also have another machine that I just finished installing gentoo 1.4 from scratch.  This machine can connect to the DSA hostkey using servers just fine.

----------

## cfactor

Here's another indication that something's whack with openssh:

http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=102512622307548&w=2

----------

## Vhata

I hope this topic is still open.

I have a Gentoo 1.2 box (nihil), and a Gentoo 1.4 box (omnia).  I use ssh-agent passphrase authentication with version 2 ssh.  When I ssh from omnia to anywhere, I get straight in.  Ditto from anywhere to omnia.  When I ssh from anywhere to nihil, I get straight in.  When I ssh from nihil to any linux box, I get straight in.

However.

I cannot ssh from nihil to any FreeBSD box without getting the "key_verify failed for server_host_key" error.  I will spare you the debug output and version numbers, unless you're really interested - there isn't much difference between them and what has already been posted to this forum.

I just thought you might be interested in the FreeBSD phenomenon - this would seem to indicate an incompatibility?  And now I think about it, all the linux boxes I try are also running Gentoo, or at the very least are running openSSH.

----------

## Vhata

I'd like to report that deleting all keys, regenerating server keys, and then recreating the public/private keys on a FreeBSD machine results in no key-authentication at all, and every single connection (except between FreeBSD machines) reverts to keyboard-password authentication.

When I manage to glue my keyboard back together, and buy a new monitor, I will pursue these investigations further...

(later)

My bad.  I didn't create authorized_keys*, I'm an idiot.

With that done, it seems that the behaviour is exactly the same.  Generate the keys on BSD or linux, it still doesn't work.

However, ssh'ing with "-o 'Protocol 1'" does, so the problem is with Protocol 2, and I suspect with the ciphers.

This gives a workaround for the time being at least.

More details as events warrant.

----------

