How to forward X over SSH to run graphics applications remotely?
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?
I 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.
One 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».
13 Answers 13
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.
@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.
+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.
@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/…
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 cat /var/run/sshd.pid | xargs kill -1 belden@skretting:~$ which xauth /usr/bin/xauth belden@skretting:~$ ssh -X blyman@the-server 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__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.
Запуск графических приложений через SSH (X11Forwarding)
На компьютер клиента передается «картинка».
На удаленном компьютере (на котором выполняется само приложение) должны быть X‘ы и все что нужно, что бы запустить программу.
Настройка клиента Windows
Установка Xming
Xming — порт сервера X Window System для операционной системы Microsoft Windows.
Скачать Xming с SourceForge и установить.
Настройка PuTTy
Просто запускаем программу в терминале
Обсуждение
спасибо, всё работает на ура! только очень тормознуто (или это только у меня так?).
Да есть такое, что тормозит жутко, даже если через локалку
Алексей, радует, что причина тормозов в данном случае — не мои кривые ручки. а что посоветуете вместо данного решения? пробую сейчас xrdp (в линуксах не шибко разбираюсь), и через rdp из winxp у меня только консольное окно появилось, рабочего стола как такового нет. думаю вот, что делать дальше. 🙂
Кроме VNC ничего другого не использовал, так что советовать мне особо нечем
у меня уже всё получилось. доставил xrdp в систему, из winxp запустил терминальную сессию на ip-адрес компа с linux, увидел окошко терминала, набрал google-chrome (ради чего всё и затевал) и получил нужное. что радует, после закрытия терминального окна и повторного входа вижу всё ту же картинку, что и до закрытия. сам не ожидал, что всё так просто получится. Алексей, спасибо за статью и успехов в делах! 🙂
тоже настроил, всё работает кроме PHPStorm. запускаю, он запускается, но картинку на клиента не передаёт, а локально отображается почему-то. А все остальные программы работают как надо, удалённо.