X forwarding: trying to forward to busy local port

[Lars Kruse]

Hi,

thanks for your time (and your replies), Darren!

> >> Do you have X11UseLocalhost set in sshd_config?  If so, what does
> >> "localhost" resolve to?
> > the setting "X11UseLocalhost" is not defined in our sshd_config - so it
> > should be the default value "yes".
> > 
> >  jackdaw:~ # grep localhost /etc/hosts
> >  127.0.0.1       localhost
> >  ::1             ip6-localhost ip6-loopback
> > 
> > So "localhost" should resolve to the ipv4 address.
> 
> Not necessarily: if nsswitch.conf goes to DNS first you might resolve 
> "localhost" to an AAAA record for ::1 (or alternate between IP4 and IP6, 
> which might explain what you're seeing).

ok - you want all the details :)

localhost resolves to 127.0.0.1:
 jackdaw:~ # getent hosts localhost
 127.0.0.1       localhost

content of nsswitch.conf:
 jackdaw:~ # grep "^[^#]" /etc/nsswitch.conf | grep -v "^$"
 passwd: compat
 group:  compat
 hosts:  files dns
 networks:       files dns
 services:       files
 protocols:      files
 rpc:    files
 ethers: files
 netmasks:       files
 netgroup:       files
 publickey:      files
 bootparams:     files
 automount:      files nis
 aliases:        files


> > Maybe the ipv4 port should be checked in x11_create_display_inet, too?
> > (if "AddressFamily" is "any")
> 
> I don't think that should be necessary: the system should return the 
> sockets of the same AF when asked for the same thing (but glancing 
> briefly at the code, sshd just passes a NULL address to getaddrinfo, so 
> unless libc does a lookup for "localhost" I'm not sure what's really 
> going on here.)

I am not too familiar with networking on this level ...
But somehow the output of the following commands looks like as if the AF
is not used consistently for X-forwarded connections.

incoming ssh connections with opened X-Forwarding listening ports for both ipv4 and ipv6:
 jackdaw:~ # netstat -lpn | grep :60[0-9][0-9]
 tcp     0   0 127.0.0.1:6016    0.0.0.0:*    LISTEN    4336/sshd: lars at not
 tcp     0   0 127.0.0.1:6010    0.0.0.0:*    LISTEN    14734/sshd:steffen
 tcp     0   0 127.0.0.1:6013    0.0.0.0:*    LISTEN    2390/sshd: jens at not
 tcp     0   0 127.0.0.1:6014    0.0.0.0:*    LISTEN    2652/sshd: michael@
 tcp     0   0 127.0.0.1:6015    0.0.0.0:*    LISTEN    3341/sshd: axel at not
 tcp     0   0 ::1:6016          :::*         LISTEN    4336/sshd: lars at not
 tcp     0   0 ::1:6010          :::*         LISTEN    14734/sshd: steffen
 tcp     0   0 ::1:6013          :::*         LISTEN    2390/sshd: jens at not
 tcp     0   0 ::1:6014          :::*         LISTEN    2652/sshd: michael@
 tcp     0   0 ::1:6015          :::*         LISTEN    3341/sshd: axel at not

clients connected to the displays via their ipv4 ports:
 jackdaw:~ # netstat -pn | grep :60[0-9][0-9]
 tcp     0   0 127.0.0.1:6013    127.0.0.1:29975  ESTABLISHED 2390/sshd: jens at not
 tcp     0   0 127.0.0.1:6014    127.0.0.1:2068   ESTABLISHED 2652/sshd: michael@
 tcp     0   0 127.0.0.1:29975   127.0.0.1:6013   ESTABLISHED 2978/firefox-bin
 tcp     0   0 127.0.0.1:6016    127.0.0.1:26911  ESTABLISHED 4336/sshd: lars at not
 tcp     0   0 127.0.0.1:6016    127.0.0.1:26910  ESTABLISHED 4336/sshd: lars at not
 tcp     0   0 127.0.0.1:29220   127.0.0.1:6013   ESTABLISHED 5075/sunbird-bin
 tcp     0   0 127.0.0.1:6016    127.0.0.1:26887  ESTABLISHED 4336/sshd: lars at not
 tcp     0   0 127.0.0.1:28349   127.0.0.1:6015   ESTABLISHED 3589/kwalletmanager
 tcp     0   0 127.0.0.1:6016    127.0.0.1:26885  ESTABLISHED 4336/sshd: lars at not
 tcp     0   0 127.0.0.1:27147   127.0.0.1:6015   ESTABLISHED 3627/opera
 [many more lines - only ipv4 ports]

As I wrote in the first mail of this thread: if the ipv4 port is
already used by another process then the clients only try to connect
to the ipv4 port (and fail) - they never use the (existing and working)
ipv6 port.

(sorry, if I am mixing up "ports" and "sockets")

I do not really know, how ssh should behave.
But the current state of the ipv4/ipv6 implementation seems to be very
likely to suffer pseudo-random connection failures for X-forwarded
sessions. This feels like a very ugly situation for me.
Or do I misunderstand something?

thanks for your time,
Lars