Sun SSH IPv6 and X11 Problem

From: Crist Clark (crist.clark@globalstar.com)
Date: Thu Jun 30 2005 - 15:36:02 EDT


I am having a problem with the Sun SSH delivered with Solaris 9. The
version string is SSH-2.0-Sun_SSH_1.0.1, and it's patched to 113273-10.

When I connect with X11 forwarding enabled, I successfully connect, but
then the server dies. I can connect fine with X11 forwarding disabled,
'ssh -x hostname'. Running the server in debug mode makes it clear
why,

   # /usr/lib/ssh/sshd -d
   debug1: sshd version Sun_SSH_1.0.1
   debug1: Bad RSA1 key file /etc/ssh/ssh_host_rsa_key.
   debug1: read SSH2 private key done: name rsa w/o comment success 1
   debug1: load_private_key_autodetect: type 1 RSA
   debug1: Bad RSA1 key file /etc/ssh/ssh_host_dsa_key.
   debug1: read SSH2 private key done: name dsa w/o comment success 1
   debug1: load_private_key_autodetect: type 2 DSA
   debug1: Bind to port 22 on 0.0.0.0.
   Server listening on 0.0.0.0 port 22.
   debug1: Server will not fork when running in debugging mode.
   Connection from 192.168.153.19 port 1369
   debug1: Client protocol version 2.0; client software version OpenSSH_3.7.1p2
   debug1: match: OpenSSH_3.7.1p2 pat ^OpenSSH
   Enabling compatibility mode for protocol 2.0
   debug1: Local version string SSH-2.0-Sun_SSH_1.0.1
   [snip the usual keying and authentication noise]
   debug1: Entering interactive session for SSH2.
   debug1: fd 9 setting O_NONBLOCK
   debug1: fd 10 setting O_NONBLOCK
   debug1: server_init_dispatch_20
   debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384
   debug1: input_session_request
   debug1: channel 0: new [server-session]
   debug1: session_new: init
   debug1: session_new: session 0
   debug1: session_open: channel 0
   debug1: session_open: session 0: link with channel 0
   debug1: server_input_channel_open:confirm session
   debug1: session_by_channel: session 0 channel 0
   debug1: session_input_channel_req: session 0 channel 0 request pty-req reply 0
   debug1: session_pty_req: session 0 alloc /dev/pts/2
   debug1: session_by_channel: session 0 channel 0
   debug1: session_input_channel_req: session 0 channel 0 request x11-req reply 0
   debug1: Recieved request for X11 forwarding with auth spoofing.
   debug1: bind port 6010: Address already in use
   debug1: bind port 6011: Address already in use
   debug1: bind port 6012: Address already in use
   debug1: bind port 6013: Address already in use
   debug1: bind port 6014: Address already in use
   debug1: bind port 6015: Address already in use
   debug1: bind port 6016: Address already in use
   debug1: bind port 6017: Address already in use
   debug1: bind port 6018: Address already in use
   debug1: bind port 6019: Address already in use
   [snip etc., etc.]
   debug1: bind port 6995: Address already in use
   debug1: bind port 6996: Address already in use
   debug1: bind port 6997: Address already in use
   debug1: bind port 6998: Address already in use
   debug1: bind port 6999: Address already in use
   Failed to allocate internet-domain X11 display socket.
   debug1: session_by_channel: session 0 channel 0
   debug1: session_input_channel_req: session 0 channel 0 request shell reply 0
   debug1: PAM establishing creds
   debug1: PAM setting tty to "/dev/pts/2"
   debug1: Received SIGCHLD.
   debug1: fd 12 setting O_NONBLOCK
   debug1: fd 11 IS O_NONBLOCK
   debug1: tvp!= NULL kid 1 mili 100
   debug1: session_by_pid: pid 853
   debug1: session_exit_message: session 0 channel 0 pid 853
   debug1: session_exit_message: release channel 0
   debug1: channel 0: write failed
   debug1: channel 0: output open->closed
   debug1: channel 0: close_write

As you can see, it seem to think all of the ports from 6010-6999 are
already in use. A quick look at 'netstat -an' will show me that in
fact, none are in use.

I went to truss to see if the bind calls were really failing,
and sure enough, this is what I see,

   8149: so_socket(PF_INET6, SOCK_STREAM, IPPROTO_IP, "", 1) = 10
   8149: bind(10, 0x000D0EE0, 32, 3) = 0
   8149: so_socket(PF_INET, SOCK_STREAM, IPPROTO_IP, "", 1) = 11
   8149: bind(11, 0x000D7B70, 16, 3) Err#125 EADDRINUSE
   8149: shutdown(11, 2, 1) Err#134 ENOTCONN
   8149: close(11) = 0
   8149: shutdown(10, 2, 1) Err#134 ENOTCONN
   8149: close(10) = 0
   8149: so_socket(PF_INET6, SOCK_STREAM, IPPROTO_IP, "", 1) = 10
   8149: bind(10, 0x000D0F08, 32, 3) = 0
   8149: so_socket(PF_INET, SOCK_STREAM, IPPROTO_IP, "", 1) = 11
   8149: bind(11, 0x000D7BB8, 16, 3) Err#125 EADDRINUSE
   8149: shutdown(11, 2, 1) Err#134 ENOTCONN
   8149: close(11) = 0
   8149: shutdown(10, 2, 1) Err#134 ENOTCONN
   8149: close(10) = 0
   8149: so_socket(PF_INET6, SOCK_STREAM, IPPROTO_IP, "", 1) = 10
   8149: bind(10, 0x000D0DF0, 32, 3) = 0
   8149: so_socket(PF_INET, SOCK_STREAM, IPPROTO_IP, "", 1) = 11
   8149: bind(11, 0x000D7BA0, 16, 3) Err#125 EADDRINUSE
   8149: shutdown(11, 2, 1) Err#134 ENOTCONN
   8149: close(11) = 0
   8149: shutdown(10, 2, 1) Err#134 ENOTCONN
   8149: close(10) = 0
   [etc., etc.]

It is getting EADDRINUSE errors when it tries to bind the
socket to the port. The daemon is binding the IPv6 TCP socket
first, successfully, and then tries the IPv4 and fails. On a system
that works without problems, I see,

   14510: so_socket(PF_INET6, SOCK_STREAM, IPPROTO_IP, "", 1) = 14
   14510: bind(14, 0x000D0C58, 32, 3) = 0
   14510: so_socket(PF_INET, SOCK_STREAM, IPPROTO_IP, "", 1) = 15
   14510: bind(15, 0x000D51F8, 16, 3) = 0
   14510: listen(14, 5, 1) = 0
   14510: listen(15, 5, 1) = 0

And if I start SSH like so on the troubled system,

   # /usr/lib/ssh/sshd -4

It works fine. Looks like something funky with IPv6 and IPv4 TCP
interaction? Anyone seen this before? I have the above workaround,
but I'd like to fix this. I also wonder what other IPv6-aware apps
might break because of this.

-- 
Crist J. Clark                               crist.clark@globalstar.com
Globalstar Communications                                (408) 933-4387
The information contained in this e-mail message is confidential,
intended only for the use of the individual or entity named above.
If the reader of this e-mail is not the intended recipient, or the
employee or agent responsible to deliver it to the intended recipient,
you are hereby notified that any review, dissemination, distribution or
copying of this communication is strictly prohibited.  If you have
received this e-mail in error, please contact postmaster@globalstar.com
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers


This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:31:00 EDT