Fixing X11 Forwarding Over SSH and with Sudo

X11 forwarding over SSH not working? Not setting $DISPLAY correctly in your shell? Having problems with X11 and sudo? Yeah, me too. Total pain in the duff. Here’s what I do to fix it. I’m thinking about Linux when I write stuff like this but a lot of this has worked on AIX and Solaris, too.

  • Make sure your SSH client supports X11 Forwarding and that it’s turned on. I use SecureCRT but I know it works in PuTTY as well. Once you turn it on in your client & save the settings you will need to reconnect, the forwarding is established with the connection.
  • Ensure xauth and xterm are installed. You need xauth for this to work, and xterm is a lightweight way to troubleshoot this stuff (just run “xterm” at a shell prompt and a window should pop open).
  • If you are using a command-line client, or forwarding across multiple hosts, is X11 forwarding enabled in your ~/.ssh/config file? Add “ForwardAgent yes” and “ForwardX11 yes” to it. You can also force it with “ssh -X user@host” when you connect.
  • Do you have an X Windows server running on your desktop PC? I use Windows on my desktop and I use VcXsrv. Make sure it’s started and running. VcXsrv asks me how I want to run it, I always choose “Multiple windows,” set the display number to -1 to let it choose, and start no client. You can futz with the rest once you know it’s working.
  • Is your $DISPLAY variable being set but you get errors? If so, that’s usually not forwarding, that’s something on your PC. Check your $DISPLAY with “echo $DISPLAY” at a prompt. It should have something in it like “localhost:10.0” or “localhost:13.0” or so. Does your X Windows server software (VcXsrv) have permissions? If so, set them wide open (allow all hosts to connect).
  • On your SSH server do you have “X11Forwarding yes” and “AllowAgentForwarding yes” in sshd_config? If it’s commented out uncomment it and restart the SSH daemon (“service sshd restart” works on a lot of distros).
  • Is your home directory writable? When you log in it’ll need to create an ~/.Xauthority file and if it cannot do that you’ll have problems.
  • Is your ~/.ssh directory writable and correct permissions? It should be owned by your user and chmod 700. Things in it should be chmod 600.
  • Is there an old ~/.Xauthority file sitting there? Try removing it and logging in again.
  • Did you disable IPv6? If you run “sysctl net.ipv6.conf.all.disable_ipv6” and it comes back as 1, or “lsmod | grep ipv6” shows nothing you might have IPv6 disabled. Turns out OpenSSH hates that and has a very passive-aggressive way of showing it. Add “AddressFamily inet” to your sshd_config and restart the daemon. That forces it back to IPv4 only.
  • Are you trying to run something as root using sudo or su? Getting “X11 connection rejected because of wrong authentication?” That gets funky because of permissions with xauth. There are lots of tricky fixes with xauth but I’ve just found copying my .Xauthority file to my target user works great. Then you can “sudo xterm” with impunity. You might try avoiding “sudo su -” as the hyphen wipes your environment out, and along with it your $DISPLAY. Just try “sudo -u targetusername command” instead.
sudo cp ~plankers/.Xauthority ~root/.Xauthority
  • If you’ve gotten this far and you’re still not able to run ‘xterm’ and have it pop a window open I’m surprised. Try SSHing with debugging on, “ssh -v -X user@host” and see if it tells you what’s wrong. Add more “v” to increase the debugging level, like “ssh -vv -X user@host.”
  • What do the logs say when you connect to the server? A lot of times when there’s something wrong it’ll put something in the logs about what it is.
  • Absolute vanilla installs of Linux distributions usually work fine. As a last resort try a VM running a stock installation of something like Ubuntu and see what happens.

Good luck! I hope at least some of this helps.

Comments on this entry are closed.

  • I’ve had good luck with sudo -e (or is -E) which preserves your own environment variables. There’s some stuff I can’t get to run otherwise.

  • There’s a way to work around the environment clobber problem without having to overwrite another user’s .Xauthority file. I do things this way since it’s often required to have the target user’s environment (think old-school stuff like installing Oracle).

    [xxx@cokecan ~]$ echo $DISPLAY
    localhost:10.0
    [xxx@cokecan ~]$ xauth list
    cokecan.xxx.xxx/unix:10 MIT-MAGIC-COOKIE-1 1d2de32f474361e4486ce13b64c44f70
    [xxx@cokecan ~]$ sudo su –
    [sudo] password for xxx:
    Last login: Sun Jun 3 00:45:41 EDT 2018 on pts/0
    [root@cokecan ~]# xauth add cokecan.xxx.xxx/unix:10 MIT-MAGIC-COOKIE-1 1d2de32f474361e4486ce13b64c44f70

    Hope this helps!

    • Yeah, there’s all sorts of tricks with “xauth add $(xauth -f ~olduser/.Xauthority list | tail -1)” but they tend to be more involved. Copying the file the one time someone needs to run the Oracle installer is just easier to explain to someone with weaker UNIX-fu.

  • Depending on your system distribution, using ssh -Y instead of ssh -X might help too (or setting “ForwardX11Trusted yes”, which currently is the default in Debian and Ubuntu).