Host key verification failed.

[Bob Manocchia]

I am running HPUX 11i V1 with the following versions of openssl:
openssl A.00.09.07e.012 Secure Network Communications Protocol
openssl 0.9.8a openssl

when I try to run sftp from this server I get the message "Host key verification failed".

What can I do to make this work.
Thanks

[Steven E. Protter · Accepted solution]

Shalom,

try this with -vvv

or ssh -vvv

To the server.

There could be an old key in .ssh/known_hosts causing this problem. Deleting it could fix it.

SEP

[Bob Manocchia]

I tried did the following to the server with the key problem from another HPUX server

sftp -vvv

I returned a whole lot of output.

I then retried the sftp from that server with the key problem and it returned the same error.

[Steven Schweda]

> I am running HPUX 11i V1 [...]

On the client, or the server, or both, or
what?

> [...] openssl A.00.09.07e.012 [...]

Not directly relevant to which sftp version
you're using. Note that "openssl" and "sftp"
are spelled differently.)

ssh -V

> when I try to run sftp [...]

Often, showing actual commands with their
actual output can be more helpful than vague
and incomplete descriptions.

> I returned a whole lot of output.

Strange, then, that I can see none of it.

> [...] and it returned the same error.

Diagnostic messages generally don't solve
problems by themselves. Sometimes they can
help one solve a problem, if one can see
them. I find that one "-v" is often enough
to elucidate common problems.

[Bob Manocchia]

I tried sftp@bmanocc@server2 and received the error. I then tried sftp -vvv bmanocc@server2 and here is the output:

root@badgers /root > sftp bmanocc@server2
Connecting to server2...
Host key verification failed.
Connection closed
root@badgers /root > sftp -vvv bmanocc@server2
Connecting to butter...
OpenSSH_4.1, OpenSSL 0.9.7e 25 Oct 2004
HP-UX Secure Shell-A.04.00.000, HP-UX Secure Shell version
debug1: Reading configuration data /opt/ssh/etc/ssh_config
debug3: RNG is ready, skipping seeding
debug2: ssh_connect: needpriv 0
debug1: Connecting to server2 [xxx.xx.xx.xxx] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/3
debug1: identity file /root/.ssh/identity type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.1
debug1: match: OpenSSH_4.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.1
debug2: fd 4 setting O_NONBLOCK
debug3: RNG is ready, skipping seeding
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: 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,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,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
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: kex_parse_kexinit: 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,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,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
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: 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: 131/256
debug2: bits set: 526/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: filename /opt/ssh/etc/ssh_known_hosts
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: filename /opt/ssh/etc/ssh_known_hosts
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: filename /opt/ssh/etc/ssh_known_hosts
debug2: no key of type 0 for host server2
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts2
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: filename /opt/ssh/etc/ssh_known_hosts
debug2: no key of type 2 for host server2
Host key verification failed.
Connection closed
root@badgers /root > sftp bmanocc@server2
Connecting to butter...
Host key verification failed.
Connection closed

I can run sftp from server2 to server1 ok but not from server1 to server2.

Hope this helps.

[Robert Salter]

Looks like it doesn't like the host in the known_host file.

debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: filename /opt/ssh/etc/ssh_known_hosts

Try removing the offending host entry from the known_host file and then ssh to the host again.

[Bob Manocchia]

How do I remove the entry in the known_hosts file. This is what I see on server2 in the /root/.ssh/known_hosts file

|1|v2MvutqAh9sA74VtxzjRwyt+tO0=|WqzLyZmSE3qQ4vfK52dKUH0q3tg= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAt4VFnkCNL439S7JPmaHFV5h+0uv969hgGwHYE4UNDMbtOcH5t5s0X5mcP3fVHrH2cWcQFaQRVxUMvAoJi6xbH7ELl8jqmZ8I3mvEyFKLB
jjyTQRfBqQ7awxR37FNd3HUjNBQy6hOPcC6sAQY2zOKpQ7krtk9l8TJfysFc4hIj6M=
|1|fGUO2wrxCyVWtTAJdC+Ox29ik9g=|kElyZ/TbyxlrOP8MnBVPg0neaLM= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAt4VFnkCNL439S7JPmaHFV5h+0uv969hgGwHYE4UNDMbtOcH5t5s0X5mcP3fVHrH2cWcQFaQRVxUMvAoJi6xbH7ELl8jqmZ8I3mvEyFKLB
jjyTQRfBqQ7awxR37FNd3HUjNBQy6hOPcC6sAQY2zOKpQ7krtk9l8TJfysFc4hIj6M=
|1|sQKzln76myLM3heVEftdTtfrpsA=|SAaqMz/+VZL3kIwFnOHyYfnVmps= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAuwcqq6bYW6wmsmBUHXGT5zTfsfPw7gsTy9yk8okZ8z8lRO7B/CsMacSOzrbsLGbrCMcw4DcV6nyx8venMXg2Rj7fKi0jgzJZvkjrj7ICL
/o7U7at9Sdb7btVVpdsdLOuYRPzduXJC1vV5hPtnlGD4ojU3C8HQWjuGq+oJOklaTM=
|1|YeC/jTMb+6x8NoG9CabUDlCzkfg=|4TmYCll5anrZodjIhxssNn8U8+8= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAuwcqq6bYW6wmsmBUHXGT5zTfsfPw7gsTy9yk8okZ8z8lRO7B/CsMacSOzrbsLGbrCMcw4DcV6nyx8venMXg2Rj7fKi0jgzJZvkjrj7ICL
/o7U7at9Sdb7btVVpdsdLOuYRPzduXJC1vV5hPtnlGD4ojU3C8HQWjuGq+oJOklaTM=

Thanks

[Bob Manocchia]

One more question. Do I remove the entry from the know_hosts file on server1(originating ssh) or on server2 (destination for the ssh command)

[Robert Salter]

Move the known_hosts file to another name and then try the ssh once more. It will prompt you if you want to add it and recreate the known_host file anew. The other entries are probably other servers, so when you do a ssh from one of them you will be prompted to add them.

[Robert Salter]

I'd do server 2 first, with the move. That seems to be the one complaining. You can move the known_host file on both, it will be recreated when you do a ssh.

[Bob Manocchia]

I renamed the /root/.ssh/known_hosts file on server2. There is no known_hosts file on server1. I then did ssh bmanocc@server2 and I get the same error.

[Steven Schweda]

> HP-UX Secure Shell-A.04.00.000, HP-UX Secure Shell version

Not the latest version available, by the way.

http://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=T1471AA

> debug2: no key of type 0 for host server2

> debug2: no key of type 2 for host server2

Apparently, you don't have host key data for
server2 in any of the expected host key data
files.

> Try removing [...]

If it's there.

Normally, the SSH client is configured to
import a missing host key the first time a
user tries to connect to a server. Looks
like this:

[...]
Host key not found from the list of known hosts.
Are you sure you want to continue connecting (yes/no)?
[...]

There's an option in the SSH client
configuration file(s) ("~/.ssh/config",
"/opt/ssh/etc/ssh_config", ... ?) which will
disable this sort of automatic host key
handling. "man ssh_config", look for
"StrictHostKeyChecking", then look at your
SSH client configuration file(s) to see if
that's set to "yes". Enabling sloppy host
key checking ("ask" is probably a little
safer than "no") might be good. Otherwise,
someone needs to add the new host key(s)
manually to a known-keys file for every new
server.

> I can run sftp from server2 to server1 ok
> but not from server1 to server2.

And did you compare the "-v[vv]" transcripts
for the two directions? (I see only one.)

[Steven Schweda]

> One more question. Do I remove the entry
> from the know_hosts file on
> server1(originating ssh) or on server2
> (destination for the ssh command)

known_hosts data are kept on the SSH client,
and describe the servers to which that client
has connected or may connect.

You might also compare file/directory
ownership and permissions between the two
systems. I know nothing, but perhaps the SSH
client ignores known_hosts files which it
can't read, or which anyone on the planet can
write.

[Steven Schweda]

> There is no known_hosts file on server1.

You do have write permission in your own
"~/.ssh" directory, right?

Can you do ssh from server1 to server1? (I
assume that server2 to server2 works.) Or
server1 to anywhere? Depending on that SSH
client configuration option, I'd expect the
SSH client to create a local known_hosts file
the first time it gets close to connecting to
any other system.

[Bob Manocchia]

I installed the latest version of Secure Shell and it works fine in all directions.
I have assigned points. Thanks for all your help.