Sharing computers on a Linux (or heterogeneous) network, Part 1
Comparing Secure shell (SSH) and Virtual Network Computing (VNC)
To effectively test and write about a wide variety of software programs, I keep a fairly large number of computers on my local network. These machines run a variety of operating systems and use a wide range of hardware configurations. Sometimes I'm evaluating a tool on various platforms; other times I'm testing and debugging a tool I've written.
Most of the machines in my network each have multiple operating systems installed in a multi-boot configuration, but several are also "headless" (no monitor or keyboard). While multi-boot loaders are nice to have around, the time spent rebooting makes detailed comparative testing of platforms rather time consuming on just one machine. Multi-boot is not very good for "side by side" comparisons. I have not evaluated any of the tools that let you "virtualize" one operating system within another, such as VMWare, Plex86, VirtualPC, SheepShaver, or others. In some respects, these tools fulfill a similar purpose as do those I'll be discussing in this article.
Several different technologies allow a user at one workstation to run an application that lives on another computer. SSH provides text terminals to remote computers; the X Window System can be used to display interactive applications on workstations other than the one where they actually run; VNC can act as a "remote-control" to an entire remote desktop. Each technology has advantages and disadvantages. They all run on Linux, but different variations (host or remote) allow interaction with various other OS environments (for heterogeneous networks). Using combinations of these tools, I can sit at one workstation (the one with the best monitor, keyboard, and chair), and run, test, and time applications on a bunch of platforms (usually without rebooting anything).
My network setup
My local network has seven nodes on it, named Apollo, Bacchus, Chaos, Delphi, Echo, Fury, and Gaia. These nodes are respectively assigned local IP addresses 192.168.1.101 through 192.168.1.107. For the most part, the same physical machine gets the same IP address when multi-booted to different operating systems (but sometimes I use DHCP, which assigns addresses above 192.168.1.200). The whole thing sits behind a hardware firewall/router, and I trust the firewall enough that I am perhaps not as paranoid as I should be about the services that run on the local machines. (Those readers who need to share computers over the public internet should worry a bit more security matters than I do. The second part of this pair of articles adds some discussion of security issues.)
I mention the above details mostly so that you can follow some shell examples I give below. The machine I actually sit at is Bacchus, and it has local IP address 192.168.1.102.
Secure shell (ssh)
The most bandwidth-friendly way of connecting computers is via a simple text shell. Non-secure tools for doing this are
rsh, but so many security problems arise using
these that it is almost always better to get
ssh installed on
the computers that need to communicate. Even though some
examples below use
telnet inside my firewall, even that
compromise is an artifact the fact that "Fury" is currently
devoted to installing and reinstalling test operating systems. Many
UNIX-like operating systems (including recent Linux
distributions) will have
ssh installed by default; if not,
see Related topics later in this article for getting it set up.
Secure shell (
ssh) encrypts all the traffic that
goes over a certain channel. Since public-key encryption is
used, there is no need for the server and client to share a
key prior to session initiation. Moreover, no secrets are
transmitted in unencrypted form over the channel (such as the
login password, which
telnet transmits loudly to any
interceptor). Other protocols -- like VNC or X Window -- can be
layered on top of
ssh, but the simplest use of the protocol
is for creation of remote text consoles.
ssh, you can easily connect to machines running
different operating systems than the one on the local machine.
The only requirement is for the remote machine to have an
server running, and for the local machine to have an
client. For example, to connect my OS/2 Warp "Bacchus" machine
to the Slackware Linux "Delphi" machine in the next room is as
Connecting to remote box by HOSTS name with ssh
C:\UTILS % ssh quilty@delphi Last login: Thu Nov 29 01:41:36 2001 from 192.168.1.102 Linux 2.2.19. quilty@delphi:~$ exit logout Connection to delphi closed.
HOSTS file did not have an alias defined, I might use:
Connecting to remote box by IP with ssh
C:\UTILS % ssh email@example.com Last login: Thu Nov 29 01:51:31 2001 from 192.168.1.102 Linux 2.2.19. quilty@delphi:~$
Likewise, I frequently administer my leased Web server from across the country/world by using:
Connecting to remote box by DNS name with ssh
C:\UTILS % ssh firstname.lastname@example.org email@example.com's password:
The most difficult thing about
ssh on heterogeneous platforms
is getting the terminal configuration just right. The problem
is not really an
ssh issue per se (
telnet tends to suffer
the same range of problems). Connecting two Linux machines
together almost always works seamlessly. But often when there
is another platform involved as either client or server, the
display is not always quite right or the key bindings do
not work as expected. The problem seems especially bad when
non-UNIX-like platforms like Win32, BeOS, MacOS, and OS/2 are
involved, but even connecting FreeBSD with Linux is imperfect.
The most typical problems when you create an
between heterogeneous machines are that the codepage is wrong
or the color escape codes are wrong. When either happens,
the basic command line is available, but line-draw characters
are displayed as something else; often you also only see
monochrome terminals rather than color ones. Shell commands do
not suffer much from this "impedance mismatch", but interactive
slang-type applications usually do. The most
notable such application is a text editor, which is usually the
application you most need to run over a remote console. By the
jed is a particularly good remote text-mode editor; the strong of heart will probably use
Most other Linux/UNIX editors are either X-based or overly
crude (or obese, in the case of
There are a few things to play with if you have terminal
configuration problems. If you have are connecting to a
sshd server, try changing the remote
environment variable. For example:
Popular remote terminal settings
quilty@delphi:~$ TERM=vt100 quilty@delphi:~$ TERM=ansi quilty@delphi:~$ TERM=linux
At the same time, your local
ssh client will usually have a
way to configure the terminal type of the connection.
Depending on platform and client program, this might be a
command-line option, an environment variable, or a menu dialog.
The name you use at the two ends might not wind up being quite
the same. There is some trial and error involved here. You
might also check to make sure that you use "no codepage
translation" within your client configuration. To test the
"impedance match", try running a fullscreen remote application
jed or another editor).
Virtual Network Computing (VNC)
VNC is a client/server system that has been ported to many GUI platforms. VNC provides a lightweight protocol for displaying the entire "desktop" of a remote computer on a local system. Symantec's pcAnywhere is a commercial product with a similar purpose, but confined to Microsoft operating systems. In contract, VNC runs on literally dozens of different operating systems, and has many implementations and variations.
A good way to get a sense of VNC is to look at some of the
screenshots at its Web site (see Related topics). There are far
more possible combinations that displayed there, but the dozen
variations shown point to the multitude. In general, any
platform that has a VNC client (usually called
display the virtual desktop of any platform that has a VNC
vncviewer) within a local window. Depending on
versions of the VNC client, resizing and fullscreen options
might be available.
There is a bit of a difference between the X-based version of
VNC server (
Xvnc) and those for other platforms.
Single-user systems like Windows, MacOS, BeOS, and OS/2 do not
have a concept of "desktop sessions" the way the X Window
System does. Therefore, a Windows VNC server, for example,
just displays a remote version of the same Windows desktop that
appears on the local system; this gets called "desktop :0" when
connecting. X Window, by contrast, is multi-user and
Xvnc session creates a brand-new desktop,
and may have its own resolution, window manager, and state. In
other words, X is a lot nicer for VNC.
Once VNC server is installed, starting a session is simple and
installation is easy; see Related topics. For the
single-user platforms, you basically run the application,
no options (the first time you will need to set up some
permissions). Under X, some command-line options are helpful.
For example, I have connected a
telnet session from my local
OS/2 Warp "Bacchus" machine to the Mandrake Linux "Fury" machine
Launch VNC server sessions on Fury
[root@fury quilty]# cat /usr/bin/vnc-sessions vncserver -name TinyLinux -depth 8 -geometry 640x480 vncserver -name BigLinux -depth 32 -geometry 1260x940 [root@fury quilty]# vnc-sessions New 'TinyLinux' desktop is fury.gnosis.lan:1 Starting applications specified in /root/.vnc/xstartup Log file is /root/.vnc/fury.gnosis.lan:1.log New 'BigLinux' desktop is fury.gnosis.lan:2 Starting applications specified in /root/.vnc/xstartup Log file is /root/.vnc/fury.gnosis.lan:2.log
From the client side, I can now connect to either
Fury:2 using the local
vncviewer (or to both at once). I
could also specify
192.168.1.106:1 explicitly if I wished.
The same principle works for a non-local network, and VNC can be configured to tunnel through SSH for security purposes.
For the most part, having a
vncviewer connection to a remote
computer is functionally the same as sitting in front of the
local monitor and keyboard for that remote computer (assuming
it is not headless). Aesthetically, the remote system's
desktop will be framed by a window using the local machine's
widgets (unless you use a fullscreen option). These extra
frames can be slightly distracting at first, but they are easy to
ignore after a little usage.
Choosing the right session geometry and color-depth is
important (assuming that you are using the
Xvnc server where you
have a choice, or -- on other
vncserver platforms -- that you are
willing to toggle the remote computer's local display to a
resolution suited to your VNC needs). The smaller the remote
desktop, and the fewer colors used, the faster the display
response. Then again, screen real-estate is desirable for many
applications. I have found that reducing color-depth has
comparatively little effect on responsiveness; VNC's hextile encoding
is much more efficient than a naive pixel-by-pixel transmission
of the screen. But screen size obviously makes a difference.
In general, I find that using a remote geometry like the above
1260x940 works very nicely with my local 1280x1024 video
setting. I leave just a little bit of extra space to allow
room for the VNC titlebar, and for my local desktop's taskbar.
vncviewer window still occupies almost my whole
screen, which is nice. On a 100 Mbit ethernet connection,
this connection is hardly any worse than a local display. On
10 Mbit ethernet, you see slight delays when moving or sizing
windows. At slower speeds VNC tends not to be an optimal
solution to remote operation. Cable, DSL, or T1 connections
are still workable, but not seamless. Anything less than that
is really for an emergency only.
One problem with VNC connections is that local desktops need to
grab some keystrokes for their own purposes. Depending on the
specific client, a number of remote keystrokes might have to be
emulated with multi-keystroke operations. For example, my
vncviewer requires me to press
Alt-A, F, Alt-A
to enter a remote
Alt-F. Those extra strokes are sometimes
hard for a touch typist to adjust to. The situation is even
more complicated under non-PC platforms -- like Macs -- that have
their own keyboards and (one-button) mice. There is a bit more
to learn, and to type, but there is generally a way to emulate
any remote input action. Linux-to-Linux connections work
pretty smoothly, however. Depending on the specific window
managers used at both ends, it is usually only a few key
combinations that do not get passed through directly to the
One noteworthy implementation of VNC is the Java version.
A lot of native versions are available, but even those platforms
without a native
vncviewer can use the Java version (assuming
a JVM exists for the platform). VNC-java can run inside a
Web browser, which provides a familiar interface to establishing
the connection. But the Java viewer can also run as a Java
application outside a browser. The Related topics below
provide a bit of extra information on VNC-java, including an
archive I have created that might help some users get going.
In Part 2, we'll look at remote X and some other ways of running remote applications across networks, as well as security issues when using remote applications.
- The commercial and official version of SSH is made by SSH Communications Security. There is a version available free-of-charge for non-commercial use, but it is not Free Software.
- Most Linux distributions package OpenSSH instead. The license is a bit complicated because of parts that are inherited from various places, but it is "BSD-like".
- The site FreeSSH (not to be confused with FreSSH) provides links to a number of Free and commercial SSH implementations on numerous platforms.
- For Windows, I recommend the Free (MIT license) Software program PuTTY. It is very nice and easy to install.
- For BeOS and OS/2, I recommend searching on BeBits.com and Hobbes OS/2 archive, respectively. For MacOS, I have used MacSSH, but I have no opinion one way or the other about Nifty Telnet 1.1 SSH. Check the FreeSSH site for MacOS links.
- Some readers may want to use the Java version of VNCviewer, but
have only a Java runtime environment, not the
javacdevelopment tool, on their machine. David Mertz has created a (totally unsupported) set of bytecode compiled
.classfiles that you are welcome to try.
- Also by David Mertz on developerWorks, the three-part tutorial on cryptology concepts provides background for the "public-key encryption" mentioned in the
sshdiscussion of this article: