Bug 1317251 - X11 Forwarding using SSH of Chrome and Firefox nolonger work
X11 Forwarding using SSH of Chrome and Firefox nolonger work
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-intel (Show other bugs)
23
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-03-13 06:36 EDT by Paul van Maaren
Modified: 2016-10-09 11:53 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-10-09 11:53:00 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Paul van Maaren 2016-03-13 06:36:11 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 

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.
Comment 1 Yauhen Shulitski 2016-06-24 18:26:50 EDT
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
Comment 2 Christian Groove 2016-07-12 16:56:38 EDT
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.
Comment 3 Paul van Maaren 2016-07-13 01:57:45 EDT
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.
Comment 4 Christian Groove 2016-07-13 02:29:45 EDT
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.
Comment 5 Paul van Maaren 2016-07-13 02:45:27 EDT
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
Comment 6 Christian Groove 2016-07-13 04:35:48 EDT
You are right, after a reboot the problem was back
on my side. Sounds weired.
Comment 7 Christian Groove 2016-07-13 04:41:23 EDT
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.
Comment 8 Christian Groove 2016-07-13 05:31:26 EDT
Your solution of downgrading is also not a real
option because it does not work on my machine.
Comment 9 Paul van Maaren 2016-07-13 05:45:20 EDT
I agree, although I would not call it a solution, more a workaround...
Comment 10 Christian Groove 2016-07-15 06:59:55 EDT
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
Comment 11 Paul van Maaren 2016-07-23 18:30:04 EDT
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...
Comment 12 Christian Groove 2016-07-24 07:43:44 EDT
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.
Comment 13 Paul van Maaren 2016-10-09 09:05:54 EDT
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
Comment 14 Hans de Goede 2016-10-09 11:53:00 EDT
(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.

Note You need to log in before you can comment on or make changes to this bug.