I wasn't sure but it sounded like a host_key file problem stopping the daemon at first. Normally an ssh client will warn you if it does not hold a key for the host, or if the key changes, and then allow you to cache the new key. This design throws up the red flag on key changes and gives you a signature to verify if the key is authentic. If for some reason the key is corrupt or miss-configured then sshd *should* fail.
I see now that Paul is not having problems with the daemon failing, his problem seems to be connecting from OMVS. Verifying that the appropriate key is installed for that host in the OMVS equivelent to known_hosts would be appropriate - if not, manually doing a binary transfer of the key and installing it in known_hosts is probably a good start. I wonder, can a Windows or *nix ssh client outside of OMVS get a session to this linux server? (If that question has already been asked/answered please feel free to call me an idiot and tell me to read the post again) Steve On Wednesday 15 January 2003 20:55, you wrote: > I don't think Paul was talking about having generated passphrases for his > host keys, but that does raise the idea that he could take the passphrases > off his _personal_ keyfiles to avoid the ASCII/EBCDIC situation that David > Boyes mentioned. And, of course, if he did put passphrases on his host > keyfiles, then those should be removed as you suggested. > > Mark Post > > -----Original Message----- > From: Steven Adams [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 15, 2003 11:37 PM > To: [EMAIL PROTECTED] > Subject: Re: ssh_dss_verify: signature incorrect > > > Here's another little detail to look at. The sshd linux man page states > that > "host keys must have an empty passphrase". If you set a passphrase on the > key > that you gen'd for your server host, try regenerating that key with > ssh-keygen -q -b <bits> -t <type> -f /etc/ssh/ssh_host_key -N (consult your > host configuration for details as configurations may vary with source build > installations). > > On Wednesday 15 January 2003 19:54, you wrote: > > Super-dumb-question: Are you sure the key generation routines in the code > > are using the same character sets (ie ASCII) during the compare? A > > EBCDIC input passphrase and a ASCII input passphrase won't produce the > > same key outputs... > > > > -- db > > > > ----- Original Message ----- > > From: "paultz" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Wednesday, January 15, 2003 7:09 PM > > 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 > > > In-Reply-To: <[EMAIL PROTECTED]> > > > > > > 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
