Are new SSH versions buggy?

From: Andreas Meile (andreas@hofen.ch)
Date: 05/17/02 

From: "Andreas Meile" <andreas@hofen.ch>
Date: Fri, 17 May 2002 17:12:19 +0200

Dear Linux and SSH users

I often need the port forwarding feature in SSH, for example to access to a
W2K server with a command like this one:

ssh -g -L 3389:w2kserv.company.loc:3389 -l user firewalls.address.com

On the company's firewall, port 22 is forwarded. This worked without issues
on my old SuSE Linux installations until version 7.1

Recently, I installed SuSE Linux 8.0 (from scratch, i.e. no update) and
there this makes a lot of trouble. :-( So, first I get

bind: Address already in use

error messages, although port 3389 in this case was _not_ used by another
process. I even can use an arbitrary port in the command above, this message
still appears.

I run this command with "-v" option so you can see the trace:

OpenSSH_3.0.2p1, SSH protocols 1.5/2.0, OpenSSL 0x0090603f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Seeding random number generator
debug1: Rhosts Authentication disabled, originating port will not be
trusted.
debug1: restore_uid
debug1: ssh_connect: getuid 504 geteuid 0 anon 1
debug1: Connecting to firewalls.address.com [123.45.67.89] port 22.
debug1: temporarily_use_uid: 504/500 (e=0)
debug1: restore_uid
debug1: temporarily_use_uid: 504/500 (e=0)
debug1: restore_uid
debug1: Connection established.
debug1: read PEM private key done: type DSA
debug1: read PEM private key done: type RSA
debug1: identity file /home/user/.ssh/identity type -1
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_2.9p1
debug1: match: OpenSSH_2.9p1 pat ^OpenSSH
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.0.2p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv key bits set: 113/256
debug1: bits set: 1037/2049
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'firewalls.address.com' is known and matches the RSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:34
debug1: bits set: 1021/2049
debug1: ssh_rsa_verify: signature correct
debug1: kex_derive_keys
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: waiting for SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: authentications that can continue:
publickey,password,keyboard-interactive
debug1: next auth method to try is publickey
debug1: try privkey: /home/user/.ssh/identity
debug1: try privkey: /home/user/.ssh/id_rsa
debug1: try privkey: /home/user/.ssh/id_dsa
debug1: next auth method to try is keyboard-interactive
debug1: authentications that can continue:
publickey,password,keyboard-interactive
debug1: next auth method to try is password
debug1: packet_send2: adding 64 (len 59 padlen 5 extra_pad 64)
debug1: ssh-userauth2 successful: method password
debug1: Connections to local port 3389 forwarded to remote address
w2kserv.company.loc:3389
debug1: Local forwarding listening on :: port 3389.
debug1: fd 4 setting O_NONBLOCK
debug1: channel 0: new [port listener]
debug1: Local forwarding listening on 0.0.0.0 port 3389.
bind: Address already in use
debug1: fd 7 setting O_NONBLOCK
debug1: channel 1: new [client-session]
debug1: send channel open 1
debug1: Entering interactive session.
debug1: ssh_session2_setup: id 1
debug1: channel request 1: shell
debug1: channel 1: open confirm rwindow 0 rmax 16384

Trying use TSCLIENT to get a session on the W2K server:

debug1: Connection to port 3389 forwarding to w2kserv.company.loc port 3389
requested.
debug1: fd 8 setting O_NONBLOCK
debug1: channel 2: new [direct-tcpip]
debug1: channel 2: open confirm rwindow 32768 rmax 16384
debug1: channel 2: rcvd eof
debug1: channel 2: output open -> drain
debug1: channel 2: rcvd close
debug1: channel 2: input open -> closed
debug1: channel 2: close_read
debug1: channel 2: obuf empty
debug1: channel 2: output drain -> closed
debug1: channel 2: close_write
debug1: channel 2: send close
debug1: channel 2: is dead
debug1: channel 2: garbage collecting
debug1: channel_free: channel 2: direct-tcpip: listening port 3389 for
w2kserv.company.loc port 3389, connect from ::ffff:192.168.1.10 port 1082,
nchannels 3
debug1: client_input_channel_req: channel 1 rtype exit-status reply 0
debug1: channel 1: rcvd eof
debug1: channel 1: output open -> drain
debug1: channel 1: rcvd close
debug1: channel 1: input open -> closed
debug1: channel 1: close_read
debug1: channel 1: obuf empty
debug1: channel 1: output drain -> closed
debug1: channel 1: close_write
debug1: channel 1: almost dead
debug1: channel 1: gc: notify user
debug1: channel 1: gc: user detached
debug1: channel 1: send close
debug1: channel 1: is dead
debug1: channel 1: garbage collecting
debug1: channel_free: channel 1: client-session, nchannels 2
debug1: channel_free: channel 0: port listener, nchannels 1
debug1: fd 2 clearing O_NONBLOCK
Connection to firewalls.address.com closed.
debug1: Transferred: stdin 0, stdout 0, stderr 38 bytes in 85.5 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.4
debug1: Exit status 0

In some other cases, I needed to use the blank IP address instead DNS host
name, although the name resolution works on the affected machine.

Does anybody know about bugs or important changes in the default
/etc/ssh/ssh[d]_config file which could cause such problems?

Another problem: Sometimes, when I logout, the connection still hangs. In
another shell on the SSH server, my session appears with a "?" as "tty" in
the "who" user list. This effect also never appeared in the old versions.

I also tried options like "-1", "-2" (force specific protocol versions) and
"-4" (force IPv4) but this doesn't help.

It may be also a SuSE bug, because on a FreeBSD 4.5 server it worked without
problems.

Any hints and advices for that problem are appreciated. :-)

           Andreas

Relevant Pages

  • X11 forwarding help
    ... I'm using ssh to do X11 forwarding over a gateway and it seems to work fine ... debug1: Rhosts Authentication disabled, ... debug3: check_host_in_hostfile: match line 5 ... debug1: channel 0: new ...
    (SSH)
  • RE: X11 forwarding help
    ... Subject: X11 forwarding help ... debug1: Rhosts Authentication disabled, ... debug3: check_host_in_hostfile: match line 5 ... debug1: channel 0: new ...
    (SSH)
  • Tru64 Unix v5.1B SSH2D chroot environment
    ... The ssh daemon that came with the system has this feature. ... I can only imagine that the client software is ... Opened channel for session ... debug1: ssh-userauth2 successful: method password ...
    (comp.unix.tru64)
  • RE: port forwarding and oracle
    ... Objet: port forwarding and oracle ... forward the connection (using java thin client drivers) through it times ... debug1: Connection to port 2521 forwarding to dbserver port 1521 requested. ... debug1: channel 3: new ...
    (SSH)
  • OpenSSH closing prematurely
    ... I'm using OpenSSH 3.02 to forward a local port to a remote port over ssh and ... debug1: Rhosts Authentication disabled, ... debug3: start over, passed a different list publickey,password ... debug1: channel 1: obuf empty ...
    (comp.security.ssh)