Create a gist now

Instantly share code, notes, and snippets.

A note on X11-Forwarding in SSh.

I used to think that

ssh -X

"just bloody worked". However this might not work - ssh must play ball on both sides of the link. On the remote (ssh server, X client) sshd must sit behind some port, tell Xlib to send X11 requests to it and then forward them back to you the X server (where the ssh client is). If the remote box is locked down to prevent this, you will get:

X11 forwarding request failed on channel 0

as part of an otherwise working login. As it happens, I am the admin of the remote box in question, so I followed the ArchWiki and went to /etc/ssh/sshd_config and uncommented

X11Forwarding yes
X11DisplayOffset 10 
X11UseLocalhost yes
  • This guy, got the same error message for a completely different reason, so you might want to look into that too.

  • In the comments, simon04 says there is yet another way for this to happen because of IPv6 issues. So you might want to look into that too.

The more likely cause of trouble is that some clients will try to do things that X thinks are dangerous and end up crashing because of BadRequest. Now is the time to sit on your hands. Do you really want to use that program? Do you really trust the box that it is running on? If the answer to both of those questions is "yes", then the best thing is to use

ssh -Y

But only on those occasions when you need it. Otherwise, keep using -X or (better!) nothing a all. The rule here is:

ssh    -- a remote trojan can find exploit some hole your ssh client and take over your local account.
ssh -X -- as above, but it can also exploit your X server and thus root your box.
ssh -Y -- as above, but it can also (without needing to find exploits), take screenshots and keylog you.

Have fun.

simon04 commented Mar 6, 2012

I'm running ArchLinux and was affected by the X11 issue, too. I fixed it in the following way (on the SSH server):

  1. Started sshd in debug mode (sudo rc.d stop sshd, sudo /usr/sbin/sshd -d)
  2. Noticed Failed to allocate internet-domain X11 display socket. in debugging output
  3. The page indicates a possible relation to IPv6 being disabled.
  4. Checked sysctl net.ipv6.conf.all.disable_ipv6, and indeed, IPv6 was disabled.
  5. Re-enabled by undoing
    5'. Alternatively, adding AddressFamily inet to /etc/ssh/sshd_config would have also worked

Hi simon. Thanks for that I have edited my gist the point to your comment. As you probably guessed, I just use this gist to store info in case come up against the same problem again. The more possible diagnoses that are there, the better.

I am glad to see that people can see what I have written. But if I want to be really helpful I should be posting this stuff up somewhere else, but then "somewhere else" probably already has a whole lot of documentation.


gurjeet commented Jul 4, 2012

In my case ssh -v user@remote showed that xauth program was not installed on my CentOS 6 remote machine. Installing that reolved my problem.

grinapo commented Aug 5, 2012

Since this comment is pretty high on google results I'll write it here:
If you intend to have ipv6 and it sill fails it could be possible that the server cannot bind to ::1, in my case because 'lo' was configured ipv4 only. adding ::1 address to lo solved the problem.

yeison commented Sep 24, 2012

For verbose ssh output, connect with:
ssh -v -X

Make sure that xauth is installed on the remote machine.

peterjc commented Oct 15, 2012

Thanks for posting this - the verbose type from @yeison showed our problem was also missing xauth on the remote machine.

peterjc commented Oct 15, 2012

Seems can't edit comments... odd, you can elsewhere in GitHub. Anyway - thanks @gurjeet for the ssh verbose and xauth tip :)


I had to patch the above problem to get it working. The one line formula would be

[ ! -x "$( strings /usr/sbin/sshd | grep bin/xauth )" ] && ln -s $(which xauth) $(strings /usr/sbin/sshd | grep bin/xauth)


I had disabled IPv6 on my Ubuntu 12.04 box a while back while setting up dynDNS. Adding the AddressFamily inet to /etc/ssh/sshd_config from Simon's answer fixed my broken X11 forwarding. Thanks!


Thanks for this. There are a lot of suggestions on how to fix this issue, but your suggestions were key. It seems that in some distributions, X11Forwarding is on, while off in others, by default.

unhammer commented Jul 3, 2015

on Xubuntu 15.04 I need X11UseLocalhost no to avoid X11 forwarding request failed on channel 0 (my arch box has the default yes)

jan-ll commented Aug 12, 2016

If enabling Ipv6 is not an option, so as to our specific environment, message posted by simon04 [commented on Mar 6, 2012] saved a day!
5. Alternatively, adding AddressFamily inet to /etc/ssh/sshd_config would have also worked
And I do confirm: it just worked !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment