Linux sshd dumps core unless client is insecure.

[Andrew Donkin]

pausmith at nortelnetworks.com (Paul D. Smith) had a problem where his
2.1.1p1 wouldn't connect if it was running set-UID root, unless "-P" was
given.

Gert Doering <gert at greenie.muc.de> suggested a firewall problem.

Damien Miller <djm at mindrot.org> tried to help too.


Now I've got the same problem: my 2.1.1p1, 1.2.2, and 1.2.3 clients won't
connect to *some* ssh 1.2.2 and 1.2.3 servers, if the following is true:

- I am not root, and
- the client is set-UID root.  Hence I cannot strace it.
- "-P" is not given
- I have no "~/.[rs]hosts" entry on the server (i.e. I supply a password)
- the server sshd is running on a privileged port

If I "sshd -d -p222" it only dumps core if I supply the correct password.
If I "strace sshd -d -p222" it dumps core if I give any non-null
password.  Weird, eh?

[...]
send(3, "<38>Jun 21 16:22:17 sshd[6979]: Failed rsa for ard from x.x.x.x port 866\0", 79, 0) = 79
sigaction(SIGPIPE, {SIG_DFL}, NULL)     = 0
close(3)                                = 0
write(4, "[...12 unprintable bytes...", 12) = 12
select(5, [4], NULL, NULL, NULL

[...waits while I type my password...]

)        = 1 (in [4])
read(4, "[...a bunch of binary...]", 8192) = 28
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++


So, sshd SEGVs when rhosts and RSA authentications fail and it tries
password authentication.  Everything is sweet if rhosts or RSA succeeds
or if it never attempts them.  An aside: why doesn't the SSH protocol
attempt host-based auth when insecure ports are used?

In summary:

About the only thing that has happened since this *used* to work is an
upgrade to 2.2.16, ssh 2.2.1, and ssl 0.9.5a.

It's not a firewall problem; all these hosts are on the same segment.

It's not a build problem; the same client binary works on another
machine.

It doesn't seem like a 2.2.16 problem (which was my first idea, since
2.2.16 has messed with UID-swapping), because the same binary works on
another 2.2.16 machine.

It's not a Slackware problem, since two of the problematic servers are
Debian binaries on Debian servers.

In fact I have run out of ideas, which is why I'm turning to you clever
folks.

The workaround is to use Rhosts or RhostsRSA authentication so that I
don't have to enter my password.  But that's a bit nasty and I'd rather
get this figured out for good.


Clients:
========

Kernel 2.2.16, Slackware.

SSH Version OpenSSH-1.2.3, protocol version 1.5.
Compiled with SSL.

...and:

SSH Version OpenSSH_2.1.1, protocol versions 1.5/2.0.
Compiled with SSL (0x0090581f).

Servers:
========

Kernel 2.2.16 on a Slackware installation running sshd 1.2.2.

Kernels 2.0.33 and 2.0.35 on Debian installations running sshd 1.2.2.

-- 
_________________________________________________________________________
Andrew Donkin                                             ITS.G.40, x4414