When connecting to an IPv6-enabled host with X-forwarding enabled sshd on the other end only opens a tunnel on ::1:6010 (ip6-localhost) and not 127.0.0.1:6010 (ip4-localhost). Reproducible: Always Steps to reproduce: 1. Login to a host that supports both IPv4 and IPv6 with X-forwarding turned on. ssh -X user@ipv6host Actual result: Sshd on the host you connected to only opens forwarding of port 6010 (x11-ssh-offset) on ip6-localhost, ::1, and not ip4-localhost, 127.0.0.1 as seen here: [ipv6host]# netstat -l -n | grep 6010 tcp 0 0 ::1:6010 :::* LISTEN Expected result: Sshd should open forwarding at least 127.0.0.1, but preferably both 127.0.0.1 and ::1. On a ipv4-only host everything works ok: [ipv4onlyhost]# netstat -l -n | grep 6010 tcp 0 0 127.0.0.1:6010 0.0.0.0:* LISTEN I have only tested this on Linux but it may apply to other OSes as well.
can you provide sshd -d output? i want to see any debug messages from x11_create_display_inet().
Created attachment 41 [details] Patch to configure.ac to make sshd forward X11 on both IPv6 and IPv4.
What is the meaning of DONT_TRY_OTHER_AF? It's only enabled on linux and is the source of this problem. Without it sshd opens forwarding on both IPv6 and IPv4. Are there any bad sideeffects of this?
Maybe this isn't a bug at all, maybe it's a feature. DISPLAY is set to localhost:0 and localhost doesn't resolve to ::1 as standard. Adding this line to /etc/hosts makes apps connect to the IPv6 tunnel. ::1 localhost But I still can't figure out why linux is the only system that shouldn't open the tunnel on both IPv4 and IPv6. Changing the severity to minor.
The reason is that we are running afoul of a fix to avoid a quirk in Linux's IPv6 support. IIRC a wildcard bind() on IPv4 will cause a subsequent IPv6 bind() to fail. Since we are not using wildcard binds in the localhost X11 case, the following patch should help. Please report on whether this is the case.
Created attachment 42 [details] Tries all AFs when binding to localhost
Nope that didn't work. Maybe you reversed the meaning of AI_PASSIVE? I'm attaching a patch that uses x11_use_localhost instead.
Created attachment 43 [details] Attach to both AFs even in linux when connecting to localhost
Created attachment 97 [details] Try to set IPV6_V6ONLY if available. Open ::1 and 127.0.0.1 if x11_use_localhost is set.
It would be nice to get this fixed... :-) (NOTE: I don't think all that many OS's support IPV6_V6ONLY setsockopt, but that's a separate issue.)
commited IPV6_V6ONLY solution: - (stevesk) [channels.c] bug #164 patch from YOSHIFUJI Hideaki (changed setsockopt from debug to error for now). can linux users try this?
This works for me nicely for non-IPV6_V6ONLY case. Applications that previously didn't work are now ok. This also seems to work on systems that don't have IPv6-enabled. The problem of changing debug -> error may be that OpenSSH compiled with a version which has IPV6_V6ONLY support may cease to work on an older socket library..
error() will just ensure the message is logged, and will not cause an exit. i wanted to see setsockopt failures for now.
Kevin, I applied your patch to the openssh-rpms for Red Hat 7.3 (openssh-3.1p1-3) and it works out just fine! [ipv6host]# netstat -l -n | grep 6010 tcp 0 0 127.0.0.1:6010 0.0.0.0:* LISTEN tcp 0 0 ::1:6010 :::* LISTEN
Oops. I applied YOSHIFUJI Hideaki's patch of course. And it worked.
Marco d'Itri suggested in http://bugs.debian.org/153154 that ssh should only bind to AF_INET addresses in x11_create_display_inet(), since at least the xtrans code in XFree86 doesn't support IPv6. Is this a valid approach?
Created attachment 160 [details] Patch from Marco d'Itri to bind X11 sockets only on AF_INET
i think itojun said that there are X11 over IPv6 implementations.
Can this bug be closed? Yoshifuji-san's patch was committed two years ago...
Yes this can be closed. It's been working for ages.
Thanks for that. Closing