VNC is a very nice way to run graphical (Linux+X, Microsoft, whatever) programs remotely (see my X terminal page for alternative methods, although VNC is probably the most appropriate for slower DSL-type connections). Perhaps even MORE worthwhile, VNC allows you to take over the Windows session on a remote machine - VERY handy if you need to actually show somebody how to do something.
The remote (away from you) computer must be running a VNC server, and the local computer (where you're sitting) must be running a VNC client that connects to the server. For the sake of sanity I'll call the remote VNC server "remotemachine" and the local VNC client "mymachine".
VNC runs by default over port 5900+display where display is the X display number (for Microsoft Windows the port is always just 5900). For example, if I decide to start an X session on display 1 then VNC will run over port 5901. In the following I will exclusively run VNC over an SSH Tunnel - only a crazy madman would leave a VNC session publicly available on the internet.
VNC Server setup
Setting up the server isn't difficult, but there are several methods depending upon your needs (and rights).
vncserver method: If you don't need to TAKE OVER an existing X Windows session (you just want to log in and start a new session) then the utility "vncserver" is your best bet. Although you don't need special privileges to run this method, the Debian package "vnc4server" will need to have been installed on "remotemachine".
Start by ssh'ing into "remotemachine" and run the command (exactly as written... ordering matters)
vncserver :1 -localhostThis starts up an X session on display 1 (port 5901) and instructs the VNC server to ONLY listen on "localhost". The latter maneuver is a security precaution because we should only connect to the VNC server through an SSH tunnel.
Obviously you can use higher X displays (2,3,4,...) if necessary. You can even use 0, although I generally avoid it with this method because display 0 is usually being already used at the console.
The first time that you run the above command you will be instructed to create a password - this is what you will use on the client to connect to the server. After you create a password you need to kill the server with the command (exactly as written... ordering matters)
vncserver -kill :1
We needed to kill vncserver because it needs more configuration. Go into the directory "/home/YOURUSERNAME/.vnc" and edit "xstartup". Comment out all lines and add a line similar to the following:
startkde &obviously you should use whatever window manager you like (gnome-session or whatever).
Now that the configuration files are initialized you can start and stop your VNC server sessions with the same commands (respectively)
vncserver :1 -localhost vncserver -kill :1
x11vnc method: This method is useful if you want to take over an EXISTING X Windows session on "remotemachine" that you have rights to. This means that there is an existing X Windows session running and you have ssh access to the corresponding .Xauthority file (if you are root on the remote machine then your problems are solved).
First, make sure that the Debian package "x11vnc" is installed. Your next step depends upon the nature of the existing X session. Suppose first that you want to take over the graphical login greeter "kdm" (or one of its brothers "gdm" or "xdm"). Then you MUST BE ROOT, and you must find kdm's so-called "X authority" file. For example, mine is currently located at "/var/run/xauth/A:0-8kHv3a". Then the following command exports this session to VNC:
x11vnc -localhost -auth /var/run/xauth/A:0-8kHv3a -display :0Note that I chose display 0 since in my case the kdm session is already running on X display 0 (yours probably will be, too). Note also that if anybody is already logged in at the console then you'll take over their session!
Alternatively suppose that some user named "USER" is already running a session (logged in using ANY method... kdm or not). Then you can directly take over their session with the command
x11vnc -localhost -auth /home/USER/.Xauthority -display :0assuming that you have rights to their .Xauthority file. Note that in both cases the switch "-localhost" instructs x11vnc to ONLY listen on localhost because we should use an SSH tunnel to connect for greater security.
krfb method: This program is great if there is a person on the remote machine (running KDE) and they want to INVITE you into their Windows session. This can be very useful if you need to show the other user something and/or if you cannot gain direct access to their .Xauthority file (but the user is sitting on the machine and is willing to "invite" you in). There's not much to it - just have them click on "krfb" and invite you to join their session. They will get a password that they'll have to give to you (probably via email). Give it a try.
VNC Client setup
This part is much easier. The client that you decide to use is based on your own preferences. Here are some choices that I use (there are others - these are the Debian package names AND the names of the programs)
krdc xvnc4viewerThe first is obviously the client counterpart to "krfb" and is useful in KDE (I like it quite a bit). The second is a standalone X program that does much that same thing.
First you need to set up an SSH tunnel to the remote machine. Open a terminal and execute this command (leave it open):
ssh -N -L 5900:localhost:5900+display username@remotemachineHere "5900+display" just means that you should set it to 5900 or 5901 or 5902 (etc) depending upon which display number the VNC server is using (see above). Note that it doesn't matter which "username" you log in as - the port is forwarded as long as you have an account on the remote machine (if you don't then you CANNOT USE AN SSH TUNNEL. I'll leave it to you to figure out what to do in that case).
Next (in krdc, for example) just connect to "localhost:0" because this will connect locally to port 5900 WHICH WILL THEN BE FORWARDED THROUGH TO SSH TUNNEL TO PORT 5900+display ON remotemachine. Voila!
This page has been visited times since March 26, 2005