How to forward X over SSH to run graphics applications remotely?
Solution 1
X11 forwarding needs to be enabled on both the client side and the server side.
On the client side, the -X
(capital X) option to ssh
enables X11 forwarding, and you can make this the default (for all connections or for a specific connection) with ForwardX11 yes
in ~/.ssh/config
.
On the server side, X11Forwarding yes
must be specified in /etc/ssh/sshd_config
. Note that the default is no forwarding (some distributions turn it on in their default /etc/ssh/sshd_config
), and that the user cannot override this setting.
The xauth
program must be installed on the server side. If there are any X11 programs there, it's very likely that xauth
will be there. In the unlikely case xauth
was installed in a nonstandard location, it can be called through ~/.ssh/rc
(on the server!).
Note that you do not need to set any environment variables on the server. DISPLAY
and XAUTHORITY
will automatically be set to their proper values. If you run ssh and DISPLAY
is not set, it means ssh is not forwarding the X11 connection.
To confirm that ssh is forwarding X11, check for a line containing Requesting X11 forwarding
in the output of ssh -v -X
. Note that the server won't reply either way, a security precaution of hiding details from potential attackers.
Solution 2
To get X11 forwarding working over SSH, you'll need three things in place:
- Your client must be set up to forward X11.
- Your server must be set up to allow X11 forwarding.
- Your server must be able to set up X11 authentication.
If you have both #1 and #2 in place but are missing #3, then you'll end up with an empty DISPLAY
environment variable.
Soup-to-nuts, here is how to get X11 forwarding working:
-
On your server, make sure
/etc/ssh/sshd_config
contains:X11Forwarding yes X11DisplayOffset 10
You may need to SIGHUP
sshd
so it picks up these changes.cat /var/run/sshd.pid | xargs kill -1
-
On your server, make sure you have
xauth
installed.belden@skretting:~$ which xauth /usr/bin/xauth
If you do not have
xauth
installed, you will run into theempty DISPLAY environment variable
problem. -
On your client, connect to your server. Be certain to tell ssh to allow X11 forwarding. I prefer
belden@skretting:~$ ssh -X blyman@the-server
but you may like
belden@skretting:~$ ssh -o ForwardX11=yes blyman@the-server
or you can set this up in your ~/.ssh/config
.
I was running into this empty DISPLAY
environment variable earlier today when ssh'ing into a new server that I do not administer. Tracking down the missing xauth
part was a bit fun. Here is what I did, and what you can do too.
On my local workstation, where I am an administrator, I verified that /etc/ssh/sshd_config
was set up to forward X11. When I ssh -X
back in to localhost, I do get my DISPLAY
set correctly.
Forcing DISPLAY
to get unset was not too hard. I just needed to watch what sshd
and ssh
were doing to get it set correctly. Here is the full output of everything I did along the way.
blyman@skretting:~$ mkdir ~/dummy-sshd
blyman@skretting:~$ cp -r /etc/ssh/* ~/dummy-sshd/
cp: cannot open `/etc/ssh/ssh_host_dsa_key' for reading: Permission denied
cp: cannot open `/etc/ssh/ssh_host_rsa_key' for reading: Permission denied
Instead of using sudo to force copying my ssh_host_{dsa,rsa}_key
files into place, I used ssh-keygen to create dummy ones for myself.
blyman@skretting:~$ ssh-keygen -t rsa -f ~/dummy-sshd/ssh_host_rsa_key
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/blyman/dummy-sshd/ssh_host_rsa_key.
Your public key has been saved in /home/blyman/dummy-sshd/ssh_host_rsa_key.pub.
Rinse-and-repeate with -t dsa
:
blyman@skretting:~$ ssh-keygen -t dsa -f ~/dummy-sshd/ssh_host_dsa_key
# I bet you can visually copy-paste the above output down here
Edit ~/dummy-sshd/sshd_config
to point to the correct new ssh_host
key files.
# before
blyman@skretting:~$ grep ssh_host /home/blyman/dummy-sshd/sshd_config
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
# after
blyman@skretting:~$ grep ssh_host /home/blyman/dummy-sshd/sshd_config
HostKey /home/blyman/dummy-sshd/ssh_host_rsa_key
HostKey /home/blyman/dummy-sshd/ssh_host_dsa_key
Fire up sshd
on a new port in non-detach mode:
blyman@skretting:~$ sshd -p 50505 -f ~/dummy-sshd/sshd_config -d
sshd re-exec requires execution with an absolute path
Whoops, better correct that path:
blyman@skretting:~$ /usr/sbin/sshd -p 50505 -f ~/dummy-sshd/sshd_config -d
debug1: sshd version OpenSSH_5.5p1 Debian-4ubuntu6
debug1: read PEM private key done: type RSA
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: private host key: #1 type 2 DSA
debug1: setgroups() failed: Operation not permitted
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-p'
debug1: rexec_argv[2]='50505'
debug1: rexec_argv[3]='-f'
debug1: rexec_argv[4]='/home/blyman/dummy-sshd/sshd_config'
debug1: rexec_argv[5]='-d'
Set /proc/self/oom_adj from 0 to -17
debug1: Bind to port 50505 on 0.0.0.0.
Server listening on 0.0.0.0 port 50505.
debug1: Bind to port 50505 on ::.
Server listening on :: port 50505.
Pop a new terminal and ssh into localhost
on port 50505
:
blyman@skretting:~$ ssh -p 50505 localhost
The authenticity of host '[localhost]:50505 ([::1]:50505)' can't be established.
RSA key fingerprint is 81:36:a5:ff:a3:5a:45:a6:90:d3:cc:54:6b:52:d0:61.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[localhost]:50505' (RSA) to the list of known hosts.
Linux skretting 2.6.35-32-generic #67-Ubuntu SMP Mon Mar 5 19:39:49 UTC 2012 x86_64 GNU/Linux
Ubuntu 10.10
Welcome to Ubuntu!
* Documentation: https://help.ubuntu.com/
1 package can be updated.
0 updates are security updates.
Last login: Thu Aug 16 15:41:58 2012 from 10.0.65.153
Environment:
LANG=en_US.UTF-8
USER=blyman
LOGNAME=blyman
HOME=/home/blyman
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
MAIL=/var/mail/blyman
SHELL=/bin/bash
SSH_CLIENT=::1 43599 50505
SSH_CONNECTION=::1 43599 ::1 50505
SSH_TTY=/dev/pts/16
TERM=xterm
DISPLAY=localhost:10.0
Running /usr/bin/xauth remove unix:10.0
/usr/bin/xauth add unix:10.0 MIT-MAGIC-COOKIE-1 79aa9275ced418dd445d9798b115d393
Look at the last three lines there. I fortuitously had DISPLAY
set, and had those two nice-looking lines from /usr/bin/xauth
.
From there it was child's play to move aside my /usr/bin/xauth
to /usr/bin/xauth.old
, disconnect from ssh
and stop the sshd
, then launch sshd
and ssh
back in to localhost.
When /usr/bin/xauth
was gone, I did not see DISPLAY
reflected in my environment.
There is nothing brilliant going on here. Mostly I got lucky in choosing a sane approach to try reproducing this on my local machine.
Solution 3
Make sure that:
- You've
xauth
installed on the server (see:xauth info
/xauth list
). -
On the server your
/etc/ssh/sshd_config
file have these lines:X11Forwarding yes X11DisplayOffset 10 X11UseLocalhost no
-
On the client side your
~/.ssh/config
file have these lines:Host * ForwardAgent yes ForwardX11 yes
On the client side, you've X server installed (e.g. macOS: XQuartz; Windows: Xming).
Then to do X11 forwarding using SSH, you need to add -X
to your ssh
command, e.g.
ssh -v -X user@host
then verify that your DISPLAY
is not empty by:
echo $DISPLAY
If it is, then having verbose parameter for ssh (-v
), check for any warnings, e.g.
debug1: No xauth program.
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
In case you've got untrusted X11 as shown above, then try -Y
flag instead (if you trust the host):
ssh -v -Y user@host
In case you've warning: No xauth data, you may try to generate a new .Xauthority
file, e.g.
xauth generate :0 . trusted
xauth list
See: Create/rebuild a new .Xauthority file
If you've got a different warnings than above, follow the further clues.
Solution 4
The fix is to add this line to your /etc/ssh/sshd_config
:
X11UseLocalhost no
https://joshua.hoblitt.com/rtfm/2013/04/how_to_fix_x11_forwarding_request_failed_on_channel_0/
Solution 5
Letting Ubuntu bash on Windows 10 run ssh -X
to get a GUI environment on a remote server
- First
Install all the following. On Window, install Xming
. On Ubuntu in the terminal, use sudo apt install
to install ssh xauth xorg
.
sudo apt install ssh xauth xorg
- Second
Go to the folder contains ssh_config
file, mine is /etc/ssh
.
- Third
Edit ssh_config
as administrator(USE sudo
). Inside ssh_config
, remove the hash #
in the lines ForwardAgent
, ForwardX11
, ForwardX11Trusted
, and set the corresponding arguments to yes
.
# /etc/ssh/ssh_config
Host *
ForwardAgent yes
ForwardX11 yes
ForwardX11Trusted yes
- Forth
In ssh_config
file, remove the front hash #
before Port 22
and Protocol 2
, and also append a new line at the end of the file to state the xauth file location, XauthLocation /usr/bin/xauth
, remember write your own path of xauth file.
# /etc/ssh/ssh_config
# IdentifyFile ...
Port 22
Protocol 2
# Cipher 3des
# ...
# ...
...
...
GSSAPIDelegateCredentials no
XauthLocation /usr/bin/xauth
- Fifth
Now since we are done editing ssh_config
file, save it when we leave the editor. Now go to folder ~
or $HOME
, append export DISPLAY=localhost:0
to your .bashrc
file and save it.
# ~/.bashrc
...
...
export DISPLAY=localhost:0
- Last
We are almost done. Restart your bash shell, open your Xming
program and use ssh -X yourusername@yourhost
. Then enjoy the GUI environment.
ssh -X yourusername@yourhost
The problem is also in Ubuntu subsystem on Windows, and the link is at
https://gist.github.com/DestinyOne/f236f71b9cdecd349507dfe90ebae776
Related videos on Youtube
Comments
-
Mr. Shickadance over 1 year
I have a machine running Ubuntu which I SSH to from my Fedora 14 machine. I want to forward X from the Ubuntu machine back to Fedora so I can run graphical programs remotely. Both machines are on a LAN.
I know that the
-X
option enables X11 forwarding in SSH, but I feel like I am missing some of the steps.What are the required steps to forward X from a Ubuntu machine to Fedora over SSH?
-
Mr. Shickadance about 13 yearsI know this is rather common, but I am having issues. A definitive answer for this question would be helpful for many. Lots of examples around seem omit important details.
-
Mike DeAngelo over 4 yearsOne thing to be aware of when reading about X11 is that the terminology is a little weird. Usually the machine that we are sitting at is the client, and the server is the machine that is remote to us.But in the X world, that is flipped around. The machine we are sitting at is creating windows and drawing shapes at the request of the remote machine. So the remote machine making the requests to draw is the "Client", and the local machine that is servicing those requests is the "Server".
-
-
Alen Milakovic about 13 yearsYou also need
xauth
installed on the remote machine, otherwise the x authority stuff won't work. -
Mr. Shickadance about 13 yearsWhat about setting
DISPLAY
? -
Shadur about 13 yearsssh will automatically set
$DISPLAY
ifX11Forwarding
is enabled andxauth
is present on the client system. -
user unknown about 13 yearsDon't we need sometimes to set
sudo xhost +client
? When I connect from xubuntu1 to xubuntu2, xubuntu2 running sshd, I do ssh -X from 1, on 2 I type above xhost-command, and then I start a graphical program. Is it a workaround if no modificaton of /etc/*config is wanted? -
Gilles 'SO- stop being evil' about 13 years@user: No, you never need
xhost +
.xhost
is from a gentler era when having a machine connected to the network meant you were trustworthy.xhost +
means anyone who can spoof your IP can take control of your X server session.ssh -X
will set up all the required authorizations. If X11 forwarding disabled in the server config, talk to your administrator; if that doesn't work, see Forwarding X11 over SSH if the server configuration doesn't allow it. -
user unknown about 13 yearsThanks, gilles. Since it was a 192.168.*-address, everybody in the net (eth-xlink-cable) was pretty trustworthy. :)
-
McKAMEY almost 12 yearsIs this answer valid if the client is Mac OS X? It doesn't seem to be working, just sends display to
localhost:10
. -
Gilles 'SO- stop being evil' almost 12 years@McKAMEY Yes, the client can be OSX. On the server (i.e. inside the SSH session),
$DISPLAY
is typicallylocalhost:10
(the number can vary, it's the first free number starting at 10). If$DISPLAY
is set in the ssh session, everything should work. If it doesn't, you can ask here; be sure to describe exactly what you did (contents of.ssh/config
, command line, etc.), and say precisely what is wrong (copy-paste any error message). -
vasi about 11 yearsThanks for mentioning xauth! Lack of that on a barebones server was causing me trouble.
-
puk over 10 years+1 for making the distinction between
~/.ssh/config
and/etc/ssh/sshd_config
in the same place. I could not tell if they were different' files or just a change in nomenclature. -
Khurshid Alam over 10 years@Gilles Is it still possible to use this method when server is already running a GUI environment? My home server is running basic gnome-panel classic & but when I try
ssh -X user@server
it gives me error:/usr/bin/xauth: /home/$user/.Xauthority not writable.
Any idea why? -
Gilles 'SO- stop being evil' over 10 years@KhurshidAlam It doesn't matter whether the server is also running a GUI environment. Check the permissions on the
.Xauthority
file. If using Red Hat or other system with SELinux, check the SELinux context, see unix.stackexchange.com/questions/36540/… -
Khurshid Alam over 10 years@Gilles Ok I deleted
.Xauthority
(as root) on server, now its working fine from one machine (machine-A
).I have several computers (Desktops,Netbooks, Tablets). I share same private ssh-key across all machines (just copied the~/.ssh
). But now its showing same error when I try to connect to server frommachine-B
.I think permission set by a machine (on.Xauthority
) duringssh -X
doesn't really work for other machine with same ssh-key. I wonder, if there is a nice way to share same ssh-key pair across multiple computers. -
Gilles 'SO- stop being evil' over 10 years@KhurshidAlam Your setup sounds fine, you can share the same keypair (it's purely a matter of security vs convenience). The permissions on
.Xauthority
have nothing to do with SSH. There's something unusual in your setup, post a new question and be sure to mention the permissions on.Xauthority
(output ofls -l ~/.Xauthority
), your distribution, and anything else that seems relevant. -
Malkocoglu about 10 yearsFor googlers: A Kubuntu 13.10 server and Kubuntu 13.10 client failed with "Cannot connect to X server". After investigating all other options, found that DISPLAY environment was not set automatically. So, adding DISPLAY to AcceptEnv in sshd_config solved my case. [AcceptEnv DISPLAY LANG LC_*]
-
Gilles 'SO- stop being evil' about 10 years@Malkocoglu That's odd:
DISPLAY
is not transmitted from the client to the server, it's set on the server side, so it should not be inAcceptEnv
. What value ofDISPLAY
do you get on the remote side? I suspect that your X connection isn't going through the SSH. Also I can confirm that X forwarding works out of the box on Ubuntu 13.10, without addingDISPLAY
toAcceptEnv
. -
Malkocoglu about 10 yearsBoth machines are behind distinctive firewalls on distance locations, so no other port or connection available. However, I tried removing DISPLAY from AcceptEnv, it works as intended. I must have forgotten reloading sshd_config at some point so I mixed the results of two consequtive trials. For notation, out of the box configuration did not throw any error in -v mode but was not setting DISPLAY properly.
-
Alexander Taylor almost 10 yearsafter
ssh -X
runxterm &
to get a graphical terminal as the ultimate test to see if it's working. -
Admin almost 10 yearsI think you might want to see other answers to the original question and take a moment to think how your own answer improves on them.
-
x-yuri about 9 yearsPretty useful link. This exact issue prevented X11 Forwarding from working for me. I had
~/.ssh/rc
file. And it turned it it's responsible for runningxauth
as such. -
alfonx over 8 yearsI have 2 Ubuntu server. On the one I needed it set to yes, on the other it had to be no. I am sure there is a explanation, but it's worth to try both.
-
m3nda over 8 yearsWow, thank you so much for your anwer. I was doing everything good except the
export DISPLAY=:10
. I never guessed that number of display. -
user2928048 over 7 yearsThe Definitive Guide: Configuration on the client side marked the diference
-
user2928048 over 7 yearsand X11UseLocalhost no on the server side
-
cfr about 7 years@Shadur Not for me. It works when I
export DISPLAY=:10.0
but not otherwise. Otherwise, it complains that it cannot find:0
. Maybe something else is needed for this to happen automatically? -
Klik about 6 yearsPlease clarify if you mean to put this setting on the server or client
-
41754 almost 5 yearsIt's a display offset of 10! :D
-
dijksterhuis almost 4 years@Klik
/etc/ssh/sshd_config
is on the server. Thed
stands fordaemon
-- en.wikipedia.org/wiki/Daemon_(computing) -- Clients tend not to be daemon processes. -
alper almost 4 yearsis it
AllowAgentForwarding
instead ofForwardAgent
-
Serge Stroobandt over 3 yearsOn the client side, a significant speedup can be achieved by enabling compression through the
-C
option, as in:$ ssh -X -C blyman@the-server
-
MoonCactus about 3 years@alfonx it looks like The need for
X11UseLocalhost no
depends on whether IPv6 is activated on the server, see icaci.info/posts/x11-forwarding-with-x11uselocalhost-no.html ! -
bartolo-otrit about 3 years
AddressFamily inet
insshd_config
helps if "X11 forwarding request failed on channel 0" error raises (source)