ssh hang on wrong port - is it a bug ?

[Phil Howard]

On Mon, Jun 17, 2002 at 04:04:14PM +0530, Hari wrote:

| As seen below, telnet and ftp sessions do not hang on wrong port no.
| They just print the ssh banner and exit.

They don't exit; they wait for user input.  If everything were set up
right, and you knew the protocol and could do the math in your head,
you could type stuff in to telnet when it connects to port 22 and
carry on the SSH protocol through the telnet client.  If you could
silence the other junk and had everything set up for 8-bit clean
transmission, you could get SSH to make a connection to a port which
would fire up telnet (you can do this in inetd, for example) to
another port that really runs sshd, you could make them talk.


| Wouldn't this be expected for ssh too, to exit when they get connected to a
| wrong server.

As the prior explanation mentioned, the mixed protocol negotiation
sequence led to a deadlock.

1.  ssh connects to port 23
2.  telnetd sends some negotiation option (no CRLF)
3.  ssh gets some data, but hasn't see CRLF yet, so keeps collecting
4.  telnetd waits for response to negotiation option(s)
5.  ssh waits for CRLF to finish banner before it parses it
6.  goto 4


| As for the client time out, can this be provided as a configurable option
| (with some low default values), so that ssh clients do not hang infinitely
| on a wrong port. For those with slow links, they could consider increasing
| the time-out.

Presumably, it is unlikely a script (such as a cron job) would try
to connect to the wrong port.  If the script were coded in error in
that regard, you kill the processes, fix the script, and try again.

That leaves a human to accidentally type the wrong number.  But the
human can press Ctrl-C and try again.

I made a connection with my OpenSSH 3.2.3p1 client to my FTP server
with the time command, and let it sit a while.  The server side did
the timeout in 5 minutes.  I see no problem here.

=============================================================================
phil at antares:/home/phil 32> time ssh -p 21 -l phil vega.ipal.net
ssh_exchange_identification: Connection closed by remote host
0.010u 0.000s 5:01.19 0.0% (0t+0ds 0avg 0max)k 0i+0o (345maj+85min)pf 0 swap
phil at antares:/home/phil 33>
=============================================================================


| [hari at linux hari]$ telnet 192.168.0.32 22
| Trying 192.168.0.32...
| Connected to netra (192.168.0.32).
| Escape character is '^]'.
| SSH-2.0-3.0.1 SSH Secure Shell (non-commercial)

It's in the nature of the telnet client to output whatever is sent
to it.  So it does that and waits.


| Connection closed by foreign host.
| [hari at linux hari]$ ftp 192.168.0.32 22
| Connected to 192.168.0.32.
| SSH-2.0-3.0.1 SSH Secure Shell (non-commercial)
| ftp> pwd
| Not connected.
| ftp>

It's in the nature of most FTP clients to output the banner they
receive, and maybe even all responses on the control connection,
which is a text-line-oriented protocol.  Since it got what looks
like a banner from sshd (thinking it was from ftpd), it outputs
it like it's supposed to.  Then when it sends something else,
sshd disconnects abruptly (not conforming to the FTP protocol)
and the ftp client reports the lack of connection.

-- 
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |
| phil-nospam at ipal.net | Texas, USA | http://phil.ipal.org/     |
-----------------------------------------------------------------