Skip to content

Instantly share code, notes, and snippets.

@adrianratnapala
Created October 29, 2011 17:43
Show Gist options
  • Star 23 You must be signed in to star a gist
  • Fork 4 You must be signed in to fork a gist
  • Save adrianratnapala/1324845 to your computer and use it in GitHub Desktop.
Save adrianratnapala/1324845 to your computer and use it in GitHub Desktop.
A note on X11-Forwarding in SSh.

I used to think that

ssh -X me@some.box

"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 me@trusted.box

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.

@jan-ll
Copy link

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 !

@greenyoda
Copy link

If all else fails, launch a new terminal and try again. Spent hours trying to get xeyes to play ball until I in error closed my original terminal and voila it worked with a fresh terminal!
OS Debian 9.9.

@kiteloopdesign
Copy link

I used to think that

ssh -X me@some.box

"just bloody worked"

Me too

I can confirm all options mentioned here are true and they also worked for me. Thanks

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