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 How reproducible: Everytime 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 3. Actual results: Browser does not appear Expected results: Working browser appears Additional info: 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 X11DisplayOffset 10 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 "^$|^#" HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_ecdsa_key HostKey /etc/ssh/ssh_host_ed25519_key SyslogFacility AUTHPRIV PermitRootLogin yes AuthorizedKeysFile .ssh/authorized_keys PasswordAuthentication yes ChallengeResponseAuthentication no GSSAPIAuthentication yes GSSAPICleanupCredentials no UsePAM yes X11Forwarding yes X11DisplayOffset 10 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 AcceptEnv XMODIFIERS 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 at all. As a consequence of this: no X11 is working remotly.
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 X11UseLocalHost no 2) restart sshd $ service sshd restart Tscho! https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/882878
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 xorg-x11-drv-intel-2.99.917-24.20160712.fc24.x86_64
(In reply to Paul van Maaren from comment #13) > Today I upgrade to F24, and the problem has disappeared. Apparently resolved > in: > > $ rpm -qf /usr/lib64/xorg/modules/drivers/intel_drv.so > xorg-x11-drv-intel-2.99.917-24.20160712.fc24.x86_64 Good to hear, F23 is going to go eol soon, so I do not believe this is worth tracking down / fixing in F23, closing.