ssh: "key_verify failed"

nitro322 · Guru Joined: 24 Jul 2002 Posts: 594 Location: USA

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

rac · Posted: Wed Aug 07, 2002 5:50 am Post subject:

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?
_________________
For every higher wall, there is a taller ladder

nitro322 · Guru Joined: 24 Jul 2002 Posts: 594 Location: USA

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 · Posted: Thu Aug 08, 2002 12:36 am Post subject:

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

Cid Highwind · n00b Joined: 09 Jul 2002 Posts: 53

klieber · Posted: Sat Aug 10, 2002 5:15 pm Post subject:

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
_________________
The problem with political jokes is that they get elected

Naan Yaar · Bodhisattva Joined: 27 Jun 2002 Posts: 1549

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 · Posted: Sun Aug 11, 2002 11:21 am Post subject:

Naan Yaar · Bodhisattva Joined: 27 Jun 2002 Posts: 1549

Happens with both keys and password authentication.

klieber · Posted: Sun Aug 11, 2002 1:15 pm Post subject:

Naan Yaar · Bodhisattva Joined: 27 Jun 2002 Posts: 1549

Gentoo: OpenSSH_3.4p1
Remote: OpenSSH 3.1.0

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

klieber · Posted: Sun Aug 11, 2002 3:40 pm Post subject:

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
_________________
The problem with political jokes is that they get elected

Naan Yaar · Bodhisattva Joined: 27 Jun 2002 Posts: 1549

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.

cfactor · n00b Joined: 30 May 2002 Posts: 2

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 · n00b Joined: 30 May 2002 Posts: 2

Here's another indication that something's whack with openssh:
http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=102512622307548&w=2

Vhata · Posted: Thu Oct 17, 2002 8:21 pm Post subject:

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.
_________________
No trumpets, no drums.
Jonathan Hitchcock

Vhata · Posted: Thu Oct 17, 2002 8:42 pm Post subject:

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.
_________________
No trumpets, no drums.
Jonathan Hitchcock