How to run Intellij IDE on remote computer using X Windows protocol
- How to run Intellij IDE on remote computer using X Windows protocol
- Forwarding X11 using SSH
- Forwarding X11 in depth (to forward manually or fix SSH X11 troubles)
- Authentication via PolicyKit
In some cases you need to run Intellij IDE on remote server connecting to it from your desktop. For Windows-based servers, recommended way is RDP which works pretty good but for Linux (and other *nix) one may think about VNC, but VNC performance may be too bad for most cases. The best way here is launch X Windows server locally (you probably already have one if your desktop is Linux-based, and XMing could be used for Windows) and redirect remote Intellij IDE output to your server. It is prefered to do that over SSH tunneling like SSH X11 Forwarding.
Forwarding X11 using SSH
This section contains recommended way to run IDE on remote Linux-based computer using SSH X11 Forwarding. If it works with your environment, then you probably do not need to read any further unless you are curious enough.
The only secion you should read is "Authentication via PolicyKit" below, since it may affect you anyway.
Using Linux as desktop
Make sure X-Windows (GUI) is launched in your desktop, open terminal and run:
$ ssh -X yourserver
Here, "-X" means "forward X11 to local machine." Try to launch Intellij IDE (by executing ".sh" file in "bin" folder) after it. If it works, then you are done.
Using Windows as desktop
Install XMing, launch it, download puTTY and enable X11 forwarding (see X11 forwarding putty). In "Session" type your server name, and click "Open". Launch IDE on remote machine, and check if it works.
XMing "US international keyboard" warning
If you've faced troubles with quotation marks like you have grave accent or prime mark (
`) instead of regular single or double quotes (
'), then you probably have US international keyboard layout (please read about it at MS US international keyboard layout support page). To check it, in terminal launch
$ setxkbmap -print -verbose 10 | grep layout
If you have something like "
us_intl", then you need to change it to "
us". You may provide something like "
-xkblayout us" as XMing argument, or run XLaunch.exe wizard in XMing folder and add "
-xkblayout us" on "Additional parameters" step. Wizard will create "config.xlaunch" file that can be used to launch XMing. See
"X11 forwarding request failed on channel 0" error
This error means SSH was not able to forward X11. Most common problem is lack of xauth (this tool is described in "Forwarding X11 manually" section). This tool has to be installed on server. To find package on deb-based do '$ apt-cache search xauth'. On rpm-based, do '$ yum provides xauth'.
Forwarding X11 in depth (to forward manually or fix SSH X11 troubles)
How X11 works (very briefly)
X11 uses client-server arhitecture. X-Server (XOrg on most modern Linuxes or XMing on Windows) manages display (monitor, keyboard and pointer) and accepts connectes from clients. Clients are applications that draw windows on displays and accepts keyboard and pointer events. So, X-Server is something your run on your desktop and Intellij IDE is X client. Client uses $DISPLAY variable to find server, display and screen (one server may have several displays and each display may have several screens. This about display as about your working place. You need to run IDE on your display.). This variable may point to unix domain socket or TCP port. TCP port is 6000+display_number, so 6000 is display 0, 6001 is display 1 and so on. When client sees something like "DISPLAY=xserver:20.0" it means "display on xserver host, port 6020 (6000 + 20) on screen 0".
Nowadays X Server rarely launched directly (using X, Xorg or startx). In most cases, init scripts (or systemd in modern distribs) launches X Display Manager , and display manager launches X server itself, becomes its client, and displays "login screen". So, display manager is reponsible for arguments, passed to X Server. Especially "-no-listen" which stops server from listening TCP 6000 port (and making it using unix domain socket for local connections only). GDM is popular display manager, and one should set "DisallowTCP=False" in "security" secion in "/etc/gdm/custom.conf" and enable Xorg to listen for network incoming connections. How ever, using TCP connections are insecure and you should use SSH-based X11 forwarding if only possible (see below).
Please read X server authorization article. For remote clients, there are 2 simple ways to access server. First is to add host to list of allowed hosts using something like "$ xhost +YOUR_DESKTOP_HOST" (or add host to "X0.hosts" in case of Windows/XMing). But it is not very secure. Second way is find current magic cookie (using "$ xauth list") and copy it to your server. SSH X11 forwarding creates some kind of "proxy" and you do not need to transfer magic cookie. See next section.
How SSH forwarding works
SSH has ability to do so-called "reverse tunneling". It opens port on server, and any connection to this port is forwarded to some local port. Not only it allows server to connect to client ports (which would be impossible otherwise due to firewall, proxy and sNAT used in many companies) but it also encrypts traffic making it secure. SSH uses this ability to do X11 forwarding. When client connects to server, it may pass "-X" (in case of OpenSSH client) to ask server to do X11 forwarding. If forwarding is not disabled on server side (see "X11Forwarding" for OpenSSH server), here is what happening:
- SSH on server side opens port i.e. 6010 (X11 port + some shift because port 6000 us already occupied by local X server).
- Sets $DISPLAY var. to point to it (localhost:10). Remember that port is 6000+display number.
- Creates magic cookie (that is why it needs xhost. With out of xhost it can't create and configure one).
- Any connection to this port is checked against cookie, and if cookie is ok, it is forwarded to client
- On client side, this connection is forwarded to local $DISPLAY
So, it is secure and works on any network configuration. Always use X11 forwarding if possible.
Manual X11 forwarding or working with out of SSH
If for some reason your are not able to do SSH X11 forwarding and your server and client are situated in one network, you can connect them directly. In other case, you may try ssh reverse tunnel.
Note on Windows desktops (XMing)
On XMing, list of hosts that allowed to connect are listed in "X0.hosts" file in XMing installation folder. You always need to add "localhost" there. You may also add your server domain name (or IP address) in case of "direct connections" (see below).
Skip any XOrg-specific topics (like display manager, xhost or xauth if you use Windows)
Make X11 to listen TCP 6000
To make XOrg listen for TCP 6000 port, you need to remove "-no-listen" from its arguments. Since your XOrg is launched from display manager (see "How X11 works" above), consult your display manager manual to find how to remove this argument. Reboot, and make sure your server listens to 6000. If you have netstat (classic distro), do '$ netstat -na | grep LISTEN'. If you have ss, do '$ ss --listen --tcp' (modern distro) and check for ":6000" or ":x11".
Using reverse tunneling
$ ssh -R 6020:localhost:6000 YOUR_SERVER
Now you need to set display. Since you use port 6020, display is 20:
$ export DISPLAY=:20
Last step is authorization. SSH forwards connections to your localhost, so you can simply make Xorg accept connections from localhost (on your desktop do '$ xhost +localhost'). But if your are security paranoic, you may transfer magic cookie.
Copying magic cookie
On desktop do '$ xauth list $DISPLAY'. You will find display, cookie type and cookie itself. Copy cookie with type (like "MIT-MAGIC-COOKIE-1 1234567789"). On your server do '$ xauth add $DISPLAY <STRING_THAT_YOU_COPIED>'. Now your X clients will use cookie.
Using direct connections
If server and desktop are in one IP network and you do not care about security, you may connect application directly to x server. Assume you already made your x-server listing TCP 6000 port. You then SSH to your server and
$ export DISPLAY=<YOUR_DESKTOP>:6000
You may face firewall blocking requests. Try to '$ telnet <YOUR_DESKTOP> 6000'. If connection is refused, then firewall on your desktop blocks incomming connections. It is distributive specific, how to fix it. But generally you may do something like '$ sudo iptables -A INPUT -p tcp --dport 6000 -j ACCEPT'. If you use firewalld (common case on rh based distros) '$ sudo firewall-cmd --add-port=6000/tcp' may help. Both commands do not add changes permanently, you will need to rerun it after reboot. Contact your network administrator for more information.
If telnet works, then you need to fix authorization. Everything is the same as for "Using reverse tunneling" except you do "$ xhost +<your_server>" to allow connections from it. But it is better to copy magic cookie as it described above.
Debugging X11 server
In case of any trouble, check logs: "/var/log/Xorg.0.log".
Authentication via PolicyKit
What is PolicyKit?
Some actions like installing package on system interpreter may require admin rights. Traditionally this been done with "su", but modern distribs use polkit instead. Client asks polkit daemon for some action and daemon uses authentication agent to authenticate client. Communications are done using session dbus daemon. Client finds this daemon with "DBUS_SESSION_BUS_ADDRESS" env var. Authentication agent is separate prorcess that registers itself with polkit . If polkit client can't see dbus session daemon or no authentication agent is registered, it uses pkttyagent – text-mode based authentication helper.
Using pkttyagent – text-mode auth. helper (recommended)
When you install some package on IDE running on remote server using X11 forwarding, check your ssh terminal for the following output:
==== AUTHENTICATING FOR org.freedesktop.policykit.exec ===
Just type your login and password, and everything should work. You can use something like "
pkexec ls" to see how it works for your installation. If you are OK with textual authentication, then you do not need to read further. The only trouble with pkttyagent, that it requires process to be associated with tty. One may launch IDE directly with ssh, i.e. "ssh -X server ~/pycharm/bin/pycharm.sh". It works perfectly, but installing package may lead to error like "process has no tty". We recomment not to launch IDE directly and stay with pkttyagent. How ever, here is what you can do if you need graphical auth. agent.
Running X11-based auth . agent
Running dbus-daemon session
Since polkitd communication are done using session dbus daemon, any desktop environment launches one. But if you are SSHed to server, you need to launch it yourself and set appropriate env variable, so clients will be able to find polkit and auth agent. "dbus-launch" tool launches dbus session daemon and reports its socket with env variable to stdout, so you need to do:
Start session dbus daemon and export env variables it report:
$ export $(dbus-launch)
Your "$DBUS_SESSION_BUS_ADDRESS" should now be set to dbus session daemon socket.
Findning and launching polkit auth. agent.
You then need to find authentication agent to launch. Your server may already have one. Check your security log for strings like "Registered Authentication Agent". You will see something like "
[/usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1]", and this is your agent, you may launch (with "&", to send it to background). Security log location depends on syslog config, but it is probably "
/var/log/secure" on rh-based and "
/var/log/auth.log" on debian-based (i.e ubuntu). If your auth. agent is "gnome-shell", you are in trouble: gnome-shell is window manager and authentication agent, so you can't launch it since you already have window manager. You need to install different auth. agent or stay with
To list avaliable agents on deb-based linux do '
$ apt-cache search "Authentication Agent"', and on rpm-based do '
$ yum provides "*authentication-agent*"'. You may use "polkit-kde-authentication-agent-1" or "polkit-gnome-authentication-agent-1" or some another.