Yeee-hah!
Many thanks to all who have contacted me with suggestions to try. It looks
like the problem was actually due to a race condition in ssh 2.0.13's
ssh-signer2 program. Although this is apparently fixed in 2.1beta's
version my previous tests failed because of path problems.
In case it helps anyone else out here's where I think I went wrong...
=====
--On Wednesday, March 29, 2000 1:30 pm +0300 Sami Lehtinen <[EMAIL PROTECTED]>
wrote:
> : > The problem still exists in the beta version of 2.1.
> :
> : I agree: I downloaded and built the 2.1beta in vague hope of our
> hanging : problem having been discovered and fixed ... but it still
> hangs just the : same.
>
> Did you actually install the beta, and did not just run the executable
> from the distribution directory? I remember fixing one race-condition
> in ssh-signer2, which incurred in Solaris.
I (thought I) had tried the 2.1beta version of ssh to try and sort out the
hang-on-connect problems I've been seeing. (I won't describe them all over
again!)
Just to be sure I've just now tried this again on two "pristine" machines
and HAVE GOT IT WORKING!
The problem seems to be that when I tried the 2.1beta before I installed it
into a separate tree -- /usr/local/test-ssh/ --- rather than let it put its
binaries into the "live" /usr/local/ tree. (This was because the
not-properly-working 2.0.13 was already there and I didn't want people who
were already using it to suffer.)
In the sshd_config file you can specify the path to ssh-signer2, but I had
left this at the default value, which is the commented out string
"ssh-signer2".
I suspect that when I did my tests with 2.1beta it DIDN'T use the new
/usr/local/test-ssh/ssh-signer program but instead simply looked along my
PATH for "ssh-signer". The one it found in /usr/local/bin and used was, of
course, from the 2.0.13 build with the race condition problem.
When I did my tests this time I explicitly set the path of ssh-signer2 in
the sshd_config file to /usr/local/test-ssh/bin/ssh-signer2 and all is now
well.
So I can confirm that although 2.0.13 does NOT work reliably with hostname
authentication on (at least our!) Solaris systems, 2.1beta DOES seem to.
=====
One last oddity that someone can perhaps explain to me...
When I install ssh 2 it creates a "dsa"-type hostkey in the
/etc/ssh2/{hostkey,hostkey.pub} files.
To access host2 from host1 using hostname authentication I need to copy
host1's public key across into host2's /etc/ssh2/knownhosts/ directory.
The instructions in various places say this copy should be given a name
along the lines of:
host1.site.domain.ssh-dss.pub
Of course I thought I knew better and, knowing the key was a dsa-type
rather than a dss-type, I instead named it:
host1.site.domain.ssh-dsa.pub
Of course this didn't work. (The client would only try password-based
authentication, so I presume the server didn't make hostname authentication
available to it.)
It sort of goes against my logical mind to have to store a dsa-type key in
a file named after "dss". I presume this is because of Something
Historical, presumably from a time when there was only a "dss" type of key?
[Another minor mystery is that "ssh-keygen2 -h" says that only "dsa" type
keys are available ("-t dsa"). However the source code also includes "dss"
type support. I guess this is just a case of the help text being out of
date with reality, though.]
=====
Again, many thanks to all! (And if it stops working overnight you'll hear
me screaming all the way from York! :-)
Cheers,
Mike B-)
--
The Computing Service, University of York, Heslington, York Yo10 5DD, UK
Tel:+44-1904-433811 FAX:+44-1904-433740
Web: http://www-users.york.ac.uk/~pmb1/
* Unsolicited commercial e-mail is NOT welcome at this e-mail address. *
