VNC Forwarding: An Alternative to X ForwardingX forwarding is problematic from a security point of view, for the same reason as X itself. As we will see, the design of X means that remote programs must make separate network connections back to the user; this requires yet another layer of authentication and authorization, complicating the situation and opening an avenue of attack. SSH X forwarding tries to secure this as much as possible, but it may still be unacceptable in some environments. An alternative technique is to use Virtual Network Computing (VNC) over SSH. VNC is free software developed by AT&T Laboratories in the United Kingdom, which provides remote GUI access for Unix and Windows platforms. With VNC, you can open a window on your Unix machine running X and have the desktop of a remote Windows machine appear there, so you can operate the Windows box remotely. Conversely, you can run the VNC client on a Windows machine and connect to a remote X display running on a Unix host. Since VNC involves only a single outbound connection, it is easier and safer to tunnel through SSH than X. You can find out more about VNC (and download the software) at:
or the environment variable:$ xterm -d anacreon:0 &
X is a large, deep software product whose documentation fills a dozen O'Reilly books. We've barely scratched the surface with our explanation, but you've now seen enough to understand X forwarding.$ setenv DISPLAY anacreon:0 $ xterm &
syrinx$ ssh sys1 Last login: Sat Nov 13 01:10:37 1999 from blackberry Sun Microsystems Inc. SunOS 5.6 Generic August 1997 You have new mail. sys1$ echo $DISPLAY sys1:10.0 sys1$ xeyes The "xeyes" X client appears on the screen
On the command line, you may also use -x to disable X forwarding:# SSH1, SSH2, OpenSSH ForwardX11 yes
SSH2 and OpenSSH enables X forwarding with the following options:# SSH1, SSH2, OpenSSH $ ssh -x server.example.com
# SSH2 only $ ssh2 +x server.example.com # OpenSSH only $ ssh -X server.example.com
In addition, if you compile with X support, you may set the default behavior for X forwarding. In SSH1, you can enable or disable forwarding by default in the client and the server separately, using the compile-time flags -- enable-client-x11-forwarding (or -- disable-client-x11-forwarding) and -- enable-server-x11-forwarding (or -- disable-server-x11-forwarding):# SSH1, SSH2 $ configure ... --without-x ...
In SSH2, you can enable or disable all X forwarding by default with -- enable-X11-forwarding or -- disable-X11-forwarding:# SSH1 only $ configure ... --disable-server-x11-forwarding ...
Remember, enable/disable flags simply set the default behavior. You can override these defaults with serverwide and per-account configuration.# SSH2 only $ configure ... --enable-X11-forwarding ...
The X11DisplayOffset keyword lets you reserve some X11 display numbers so sshd can't use them. This keyword specifies the lowest display number SSH may use, preventing sshd from clashing with real X servers on the lower-numbered displays. For example, if you normally run actual X servers on displays and 1, set:# SSH1, SSH2, OpenSSH X11Forwarding no # SSH2 only: either will work ForwardX11 no AllowX11Forwarding no
The XAuthLocation keyword specifies the path to the xauth program, which manipulates authorization records for X. We describe this keyword later, after we discuss xauth. [Section 220.127.116.11, "Location of the xauth program"]# SSH1, OpenSSH X11DisplayOffset 2
# SSH1, OpenSSH XAuthLocation /usr/local/bin/xauth
# SSH1, OpenSSH no-X11-forwarding ...rest of key...
You can, however, use a general port forwarding instead. For example:X11 connection requests different authenticationprotocol: 'MIT-MAGIC-COOKIE-1' vs. ''
Note that this bypasses the discipline imposed by X forwarding, of requiring xauth authentication on forwarded X connections. If your real X server is using xhost for access control, this port forwarding allows anyone on host foo to connect to your X server. Use this sort of thing with caution if you need to.foo% ssh -R6010:localhost:6000 bar bar% setenv DISPLAY bar:10
#!/bin/csh if ($?DISPLAY) then set display_host = `expr "$DISPLAY" : '\(.*\):'` set display_number = `expr "$DISPLAY" : '.*:\([^.]*\)'` set my_host = `hostname` set result = `expr '(' "$display_host" = "$my_host" ')' '&' '(' \ "$display_number" '>' "0" ')'` if ($result == 0) then echo "WARNING: X display $DISPLAY does not appear to be protected by SSH!" echo "unsetting DISPLAY variable just to be safe" unsetenv DISPLAY endif endif
if (($uid == 0) && ($?SSH_CLIENT) && ($?DISPLAY)) then # If I do ssh -l root with X forwarding, the X proxy server's xauth key # gets added to root's xauth db, not mine. See if there's an entry for my # display in root's xauth db... set key = `bash -c "xauth -i -f /.Xauthority list $DISPLAY 2> /dev/null"` # ... and if so, copy it into mine. if ($? == 0) then xauth -bi add $key chown res ~res/.Xauthority >& /dev/null endif endif
XAuthLocation can also appear in the client configuration file (OpenSSH only); the client uses xauth to get the local X display key.# SSH1, Open SSH XAuthLocation /usr/local/bin/xauth
|9.2. Port Forwarding||9.4. Forwarding Security: TCP-wrappers and libwrap|
Copyright © 2002 O'Reilly & Associates. All rights reserved.