openssh unix dev - Feb 2000 - ssh_exchange_identification fails (how to fix)

Renaud Guerin <renaudg at hexanet.fr> writes:
>I'm running OpenSSH 1.2.2. with OpenSSL 0.9.4 on Linux 2.2.14
>(Mandrake 7.0) They were recompiled from source RPMS with gcc 2.95.2
>When I try to connect to localhost, I get 
>SSH Version OpenSSH-1.2.2, protocol version 1.5.
>Compiled with SSL.
>debug: Reading configuration data /etc/ssh/ssh_config
>debug: Applying options for *
>debug: ssh_connect: getuid 0 geteuid 0 anon 0
>debug: Connecting to localhost [127.0.0.1] port 22.
>debug: Allocated local port 662.
>debug: Connection established.
>ssh_exchange_identification: read: No such file or directory
>debug: Calling cleanup 0x80572e8(0x0)
>
>When I try to connect to my remote host, I get
>ssh_exchange_identification: read: Success
>
I have a similar configuration, and was getting the same problem.  A
long look through the sources tells the tale.  Basically, the problem
can be cured by adding a line like the following to /etc/hosts.allow:

   sshd       : hostname.on.whatever.net : ALLOW

ie. Just add a line like you were enabling rlogind, but for "sshd".
This is necessary because your "sshd" was compiled with LIBWRAP
support, and since libwrap is called from "sshd", it expects to find
"sshd" in the hosts.allow.  You should be seeing the tell-tale
"connection refused" lines in the /var/log/messages file of the
machine running "sshd".

I'm not sure if this is the intended behavior, but I suspect it is
not, and could be considered a bug.  It is confusing to NOLT be using
"sshd" under inetd.conf with TCP_Wrappers, and yet still be getting
behavior as though it were.  You could also compile without LIBWRAP
to remove this behavior.

A second buglet occurs in sshconnect.c (from OpenSSH sources), in
the ssh_exchange_identification() call. Here are the relevant lines.
(lines 961-964):

	/* Read other side\'s version identification. */
	for (i = 0; i < sizeof(buf) - 1; i++) {
		if (read(connection_in, &buf[i], 1) != 1)
			fatal("ssh_exchange_identification: read: %.100s",
strerror(errno));


Notice that the conditional will fail and call fatal() if there are
zero bytes read, which is not an error condition.  Thus the "Success"
error message that you got.  The problem is that the "sshd" daemon on
the other end has refused the connection (due to LIBWRAP, see lines
749-767 of sshd.c:main()), before writing anything to the socket, so
the read gets an EOF (zero bytes read).  The program should probably
report a special case when the number of bytes read is zero
(indicating that the server has refused a connection, or is not
responding).
 
So, the documentation (FAQs, HOWTOs, man, etc.) should be updated to
explain this behavior when using "sshd" compiled with LIBWRAP, and
perhaps OpenSSH should be fixed (if this behavior is indeed not the
desired one.  At least a mention of the consequences should appear in
the "ssh" and "sshd" man pages)

Chad Netzer
cnetzer at stanford.edu

Chad Netzer writes:
> long look through the sources tells the tale.  Basically, the problem
> can be cured by adding a line like the following to /etc/hosts.allow:
> 
>    sshd       : hostname.on.whatever.net : ALLOW
Do you have a catch-all line in /etc/hosts.allow that denies
"everything", or an /etc/hosts.deny file?

eg

ALL: ALL: DENY
at the end of the file?

Michael Helm <helm at fionn.es.net> writes:
>Do you have a catch-all line in /etc/hosts.allow that denies
>"everything", or an /etc/hosts.deny file?
Yes, I should have mentioned that the "problem" only occurs
on systems that have explicit enabling of selected services.
So, by not enabling sshd in the hosts.allow file, it is
automatically denied by hosts.deny.

The problem for me really (and probably for others, like
Renaud) is that since the sshd damon is not run from inetd,
I didn't expect it to be under hosts.deny or hosts.allow
control, and the ssh error message is quite deceptive
(returning a "Success" string as the failure diagnosis :)

The INSTALL file does briefly mention the tcp_wrappers option;
it just caught me off guard.  In retrospect, however, this
behavior does appear to be the desired one, and not a bug.

Cheers,

Chad Netzer
cnetzer at stanford.edu