Paul,

What system is it that issues those messages and then exits?  The z/OS
system, or the Linux/390 one?  The permissions you talk about on the key
files are correct.  Normally, when the "could not load host key" message is
issued, there's a reason given.  Was that the whole of the messages you got?

One way to get some more information is to invoke sshd with debugging
options:
        /usr/sbin/sshd -d [-d[ -d] ]
Note that this will cause sshd to stay in the foreground, and accept one and
only one connection before exiting.

What's strange about this latest bit is that before you were getting key
validation errors, which means that sshd was running on the other system.
Otherwise you would have gotten a "connection refused" error, or just a
timeout.

Mark Post

-----Original Message-----
From: paultz [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 15, 2003 7:28 PM
To: [EMAIL PROTECTED]
Subject: Re: ssh_dss_verify: signature incorrect


Hi Tzafrir,

Maybe this is what Mark was alluding to:

When I do the diff, it reports the files are not the same.

I did an 'ssh-keygen ' for the ssh_host_key, ssh_host_dsa_key, and
ssh_host_rsa_key files.  As you point out, it also creates a public
'.pub' version of each one.

I just noticed, though, that when I /usr/sbin/sshd, it complains:
could not load host key: /etc/ssh/ssh_host_key
could not load host key: /etc/ssh/ssh_host_rsa_key
could not load host key: /etc/ssh/ssh_host_dsa_key
Disabling protocol version 1: could not load host key
Disabling protocol version 2: could not load host key
sshd:  no host keys available -- exiting

I have permissions set to 600 for the private keys, and 644 for the
public ones.

What the heck did I do to myself?

Thanks,
Paul


================================================================

From:         Tzafrir Cohen
Subject:      Re: ssh_dss_verify:  signature incorrect


On Wed, 15 Jan 2003, paultz wrote:

 > Finally got the binaries working for z/OS 1.2 USS .... sorta.
 >
 > I can go into OMVS shell under TSO, do an ssh into the same system, and
 > get logged right in, no problems.
 >
 > If I try to ssh  (from the same OMVS shell) to my RH7.2 Linux system,
I get:
 > ssh_dss_verify: signature incorrect
 > key_verify failed for server_host_key
 > .....
 > then it terminates the session.  What does it mean, 'signature
incorrect'?

Each ssh host has a host key (actually, rsa1 host key, rsa2 host key and
dsa host key). Each key is, as usual with ssh (and public keys in general)
made of two parts:

1. the public key, which is not secret, and is declared by the server
2. The secret key

The idea is that after you connect to the host for the first time you
remember the host's (public) key. Whenever you try to connect to a server
with an unknown key, the ssh client should warn you. Whenever you try to
connect to a serve to which you connected before but whose key has change,
the ssh client should give you an even nastier warning, because this can
be a sign of somebody pretending to be that server.

The public key is something everyone in the world can know, but the
private key remains a secret, it never goes on the wire (not even
encrypted). Its only use is to validate the public key: you can encrypt a
message with the public key and have the server decrypt it, as part of the
authentication protocol.

Now back to the technical details:

Have a look at the server's sshd_config . This is typically
/etc/ssh/sshd_config . THere should be there something like:

# HostKey for protocol version 1
HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key

Those files are the private keys. The public keys are *.pub , e.g:
/etc/ssh/ssh_host_dsa_key.pub for the dsa key. You can verify that they
indeed match using:

   echo "`ssh-keygen -y -f /etc/ssh/ssh_host_dsa_key` " | diff
-/etc/ssh/ssh_host_dsa_key.pub

I thought that:

   ssh-keygen -y  -f /etc/ssh/ssh_host_dsa_key | diff -
/etc/ssh/ssh_host_dsa_key.pub

would do, but it appears that in my host key there was an extra space in
the end.

--
Tzafrir Cohen

Reply via email to