Red Hat Bugzilla – Bug 1317251
X11 Forwarding using SSH of Chrome and Firefox nolonger work
Last modified: 2016-10-09 11:53:00 EDT
Description of problem:
After upgrading to xorg-x11-drv-intel-2.99.917-19.20151206.fc23.x86_64 X11 forwarding of Chrome and Firefox nolonger work. No errors, the session just hangs. After I downgraded to xorg-x11-drv-intel-2.99.917-16.20150729.fc23.x86_64.rpm it works again. I downgraded by manually downloading the rpm from http://koji.fedoraproject.org/koji/buildinfo?buildID=685358 and installing it using the following command:
rpm -Uvh --oldpackage xorg-x11-drv-intel-2.99.917-16.20150729.fc23.x86_64.rpm
Version-Release number of selected component (if applicable):
xorg-x11-drv-intel-2.99.917-19.20151206.fc23.x86_64 does not work
xorg-x11-drv-intel-2.99.917-16.20150729.fc23.x86_64 works as expected
Steps to Reproduce:
1. Login to an X11 session (I use KDE)
2. ssh into another session (local or remote) with X11 forwarding ( -X -Y) and start Chrome or Firefox
Browser does not appear
Working browser appears
Simple X11 clients as xclock and xterm do work, it is not clear to what is causing this issue. I monitored system logs using "journalctl -f" but nothing is logged when the problem appears.
I have just updated to the fedora 24 and the issue still exists with xorg-x11-drv-intel-2.99.917-23.20160512.fc24.x86_64 . However, I was able to start Chrome. Still no luck with Firefox. Downgraded back to xorg-x11-drv-intel-2.99.917-16 to make it work
It looks like an config issue to me.
Simply log in on the server and edit
the config file /etc/ssh/sshd_config
Then look for the attribute X11DisplayOffset,
that may be commented out. Change it to
and restart sshd vi
$ service sshd restart
Then try again to login from a remote client
with ssh -CY yoaccount@yoserver and the
X11 redirection should work again.
The above did not work for me. I had to downgrade to xorg-x11-drv-intel.x86_64 2.99.917-16.20150729.fc23 to make it work again.
I please take a look into your current (working
/etc/ssh/sshd_config) and post it here. There may
be a bug with the handling of x11 channels in
the intel-x11 package, but i'll guess you can
sane it by giving the X11DisplayOffset in the
sshd_config, that is owend by a ssh package.
I am also running a F23 Server, that was not
willing to establish a x11 channel.
I think it is the default config, but here you go:
# cat sshd_config | egrep -v "^$|^#"
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
Subsystem sftp /usr/libexec/openssh/sftp-server
You are right, after a reboot the problem was back
on my side. Sounds weired.
One more thing: simple clients also do not work,
because the tunnel in X11 cannot be established
As a consequence of this: no X11 is working
Your solution of downgrading is also not a real
option because it does not work on my machine.
I agree, although I would not call it a solution, more a workaround...
Ok, i got the solution. It is not an X11 issue, it
is an sshd config problem and a IP6 thing.
1) Add following line to the /etc/ssh/sshd_config
2) restart sshd
$ service sshd restart
Sorry, for the late response, I was on holiday... Anyway, I tried the above and no joy (was to be expected as I don't have IPv6 disabled as described in the above URL). At the moment downgrading is the only workaround for me...
Ough tool late.
I may also offer you to track back that problem using
strace. I think it is an issue with sshd or the way
it hat been configured.
Today I upgrade to F24, and the problem has disappeared. Apparently resolved in:
$ rpm -qf /usr/lib64/xorg/modules/drivers/intel_drv.so
(In reply to Paul van Maaren from comment #13)
> Today I upgrade to F24, and the problem has disappeared. Apparently resolved
> $ rpm -qf /usr/lib64/xorg/modules/drivers/intel_drv.so
Good to hear, F23 is going to go eol soon, so I do not believe this is worth tracking down / fixing in F23, closing.