Main page... Popular tags: Electronics (12), Linux (11), DIY (8), Hack (8), Retrocomputing (7), Other (6), Debian (5), Curiosities (4)

Two ways to work remotely on Linux

2016-09-08 00:26:03, In: Linux, Hack

At work, I have my Linux laptop and Linux workstation. Usually both are running. Sometimes I want to work on my small (12.1-inch) notebook using a nice Full-HD display and full-sized keyboard of my Workstation. Because both of these computers are in the same LAN and "see" each other IP addresses, I can use different open source solutions to connect them for remote control. Typical and well tested one is VNC (Virtual Network Computing) while older and not commonly used is X forwarding, popular in scientific software in 1980s and early 1990s (later replaced by proprietary client solutions). For some time I was working with VNC, now I switched to X forwarding. Here I'll show these solutions, their positive things and problems with them. All tests have been performed on Linux, a 64-bit Debian Jessie with TDE window manager (if you don't know, it's an older KDE). However, a test has been made to show that, contrary to common myth, it is possible to connect by X-forwarding using Windows client.

VNC

VNC, Virtual Network Computing, is a remote administration system developed by ORL (Olivetti/Oracle) in 1990s. It is multi-platform, has many implementations and uses protocols which transfer images of screen to user's VNC viewer window. The tile encoder used by most VNC implementations divides screen to small parts which are transferred when they change. This way we avoid "streaming" a whole screen when nothing happens on its parts. VNC server works in background while client is a window application which, when activated, uses cursor and keyboard to send moves, clicks and keystrokes to host.
VNC is multi-platform, so there is no problem to connect Windows machine to Linux and vice-versa. In Windows server you just have control of the desktop, but in Linux there are more things we can control. First of all, VNC server (vnc4server or tightvncserver) in Linux should always be run with some knowledge about desktop it will open. Minimum is -geometry XxY argument with width and height of desktop - viewer area needed. We can make the system look more pretty by adding -depth 24 to get a 24-bit color. If we like smaller fonts on HD screen, it's good to add -dpi 90. This way we start server which currently does nothing except opening us a blank desktop number :1 (:0 is server's desktop you look at) to remote world. If you connect then, you will probably end with blank viewer window with settings window inside to check/uncheck options and maybe xterm to launch programs.
We have to fill this desktop with Desktop Environment. It is needed to edit ~/.vnc/xstartup file to include commands to start Your desktop environment in opened remote desktop. In TDE the commands are:
twin & kicker &
I usually add konsole & there to get some terminal. In KDE probably you should write kwin instead of twin. In Gnome it's gnome-session & and in newer KDE startkde &. Remember about this ampersand: & after commands, to place environment launching in background and let later commands execute.
This way one person may work on server's controls, and the other, using the same account, through VNC using second desktop. Because it forwards desktop - a screen, applications which use graphics card directly, like OpenGL programs or hardware-enhanced video decoders will work too. Looks nice?
Unfortunately even through relatively fast 802.11g Wi-Fi link the protocol caused significant lag when e.g. scrolling large web page or moving image in a bigger design. Another problem is the clipboard which works rarely even if clipboard transfer in "VNC config" is enabled. After a few weeks of trying to correct KiCAD board design with cursor moving everywhere but not where I want I decided to look for alternative.

X forwarding through SSH

SSH is a well known remote access tool which allows to work in text mode on a remote workstation. But it also behaves like container - we can push through it whatever we need. For example we can secure FTP by passing it through SSH, it can work as HTTP proxy, but not only. Let's see how GUI in Linux works - connection between part which is made by applications and X server - the part that draws things on screen and receives input from mouse and keyboard also can be forwarded through SSH to remote machine!
To make use of it, it is important to install and secure SSH server on server machine. In Debian just install openssh-server package and, still as root, use systemctl disable ssh.service to make ssh not run at startup. There is no bigger security hole than ssh server with trivial password running all time. The next step is to configure SSH by editing /etc/ssh/sshd_config file as root and uncommenting the line with X11Forwarding no, then changing it to yes. Optionally you can uncomment and change Port line to change from 22 to something other. I've made a simple script to quickly set and disable ssh server, here it is:
#!/bin/bash sudo systemctl start ssh.service echo . echo Press Return to end SSH server! read sudo systemctl service stop ssh sudo systemctl service disable ssh
The last disabling is "just in case". After the SSH server is running on a server machine, it is only needed to connect the client to it:
ssh -X -C user@192.168.0.100
The -X parameter turns X forwarding on and -C compresses data stream to conserve bandwidth. After connecting you will be asked for user's password and land in remote machine's shell. From there you will be able to launch remote X applications which will emerge as normal windows in Your local desktop, with your local decorations (which can be a bit misleading). In my computer the only change is in window's title by adding "<@mcbx>" to it (where mcbx is remote computer's name). In the picture below, Konqueror and Tabble windows are from remote machine while PaleMoon and VirtualBox in background are from local one.

The problem is that instances of some programs may get messed up. Why? Because the traditional way in Unix to look is the application running or not is to use lock files. This way, good in academic workstations under 24/7 surveillance by always-sober Sysop, fails in home computers turned off by "pulling the plug" and used by one user, logged as another, when sometimes third tries to connect. Or when two users try to launch e.g. Firefox. So Firefox, as many other applications, uses another approach - it looks for its own instance running in one or more windows. What does it mean? If we launch Firefox on a remote machine, it will launch, find its instance in local machine and activate it or tell it to open new window. This behavior can be fixed by running remote Firefox with -new-instance argument, but not all applications have such option.
Another problem occurs when application tries to show something over typical X Window situation. OpenGL for example, as well as hardware-accelerated video decoders have significant problems.
On the other hand, clipboard now always works for text data. For other types - most types are OK, but of course file transfer is not possible as copying and pasting files cause different paths in two machines (file manager tries to copy from nonexistent path). And by transferring not images, but commands to X server everything is much faster. And it is possible to use Windows computer as client using commercial solutions like X-WinPro or free (XMinG), but windows may come distorted or resized.

Organizing Applications

With VNC, you could use your native desktop environment and application menu. With X forwarding this may not work or just confuse user. It's time to add a launcher. There is a nice tab-based launcher called Tabble, and it is present in Debian's repository. Install it in a server. In client machine, call the SSH the following way:
ssh -X -C user@192.168.0.100 tabble
You tell ssh that the program we invoke remotely is Tabble. After connecting you will see the Tabble window from X server. Configure it by holding Shift key, right-clicking on buttons and editing them. Now you can launch other programs on remote machine by just clicking buttons in a launcher.

Of course I could write about TeamViewer or similar proprietary solutions, but I don't want to. They give really good capabilities like working through NAT when computers are in separate local networks, but they all have two problems: First, they, by definition, use external relays to traverse through NAT which is a security problem. Second, and more important thing is that they are closed-source so there is no guarantee that they encrypt communication end-to-end and relay doesn't know what is flowing through it. Add these two things and you have the main problem here - for a relay all data may be easily accessible to be filtered for passwords, documents or just compromising pictures. It's safer to stay away from these solutions.

Older post... Main page Newer post...