VNC – allowing remote access to graphical desktops

VNC – allowing remote access to graphical desktops

VNC (an abbreviation for Virtual Network Computing) is a great client/server software package allowing remote network
access to graphical desktops.
TightVNC allows you to display X and Win32 desktops on remote X/Win32/Java displays.
In short, it will allow me to access my FreeBSD box from my Windows box via an X Windows interface (or the other way
around). That’s something
I’ve want to do for a while. A friend had told me about VNC, so I went to FreshPorts
and did a search for vnc. I chose TightVNC.

You should consider the security implication of using VNC over untrusted networks, such as the Internet. If you plan
on using VNC over the Internet, you should use SSH or SSL to secure the session. The documentation will direct you to
the right place.

I already had an up to date ports tree, so I installed TightVNC with this single command:

cd /usr/ports/net/tightvnc
make install

My next step was to install the Windows client from the TightVNC download
. Installation was straight forward and I won’t document it here. It’s Windows. What could go wrong?
But, should you need it, there is a TightVNC for Windows document.
In my situation, I’ll be running the VNC Server on my FreeBSD box, and a VNC Client on my Windows box. You should
note that you can do this the other way around and access your Windows box from your FreeBSB box.

Starting the server

On my FreeBSD machine, I did this:

[dan@undef:~] $ which vncserver
[dan@undef:~] $ vncserver

You will require a password to access your desktops.

xauth: creating new authority file /home/dan/.Xauthority

New 'X' desktop is

Creating default startup script /home/dan/.vnc/xstartup
Starting applications specified in /home/dan/.vnc/xstartup
Log file is /home/dan/.vnc/

[dan@undef:~] $ ps auwx | grep vnc
ps auwx | grep vnc
dan 41444 0.0 2.5 10824 9796 p0 I 9:18AM 0:36.84 Xvnc :1 -desktop X -httpd /usr/X11R6/share/tightvnc/classes -auth /home/dan/.Xauthority -geometry 1024x768 -depth 24 -rfbwait 120000 -rfbauth /home/dan/.vnc/passwd -rfbport 5901
[dan@undef:~] $

As you can see, the screen was set to 1024×768. I’ll look at changing that resolution later.
The password you just entered must be supplied when you connect to the server.
This password can be changed by running vncpasswd on the server.

Stopping the server

From man vncserver, you will see:

-kill :display
       Stops the session running on the specified display.

So to kill the server, I did this:

vncserver -kill :1
Killing Xvnc process ID 46791

where 1 is the value returned when you started vncserver.

Starting the client

In the following example, I will be using the TightVNC client. I also tried the VNC client from
I’m running a client on my Windows box. You should read the TightVNC for Windows document first.
I started the VNC Client by clicking on Start->Programs->TightVNC->TightVNC Viewer (Fast Compression). I then entered the details
of my VNC Server (

connection details

Then you will be prompted for the session password which you supplied when you started the VNC server. This
password can be changed by running vncpasswd on the server.


If all goes correctly, you should now be looking at an X session running on your FreeBSD box. Here’s what it looked like
for me:

X session

From here, it’s just like you’re on the FreeBSD box.

Changing the screen resolution

This was easier than I thought. First, I consulted the vncserver man page.
Then I supplied a value for geometry:

[dan@undef:~/.vnc] $ vncserver -geometry 1280x1024

New 'X' desktop is

Starting applications specified in /home/dan/.vnc/xstartup
Log file is /home/dan/.vnc/

[dan@undef:~/.vnc] $

Changing the Window manager

The window manager is started by the ~/.vnc/xstartup script. By default, VNCTight
uses twm as that is available on most Unix platforms. Here is the original script:

[dan@undef:~/.vnc] $ less xstartup.original

xrdb $HOME/.Xresources
xsetroot -solid grey
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
twm &
[dan@undef:~/.vnc] $

My window manager of choice is KDE. To use that, I changed twm
to startkde. From then on, I got KDE on my VNC:


VNC Madness

You can connect to the same VNC server session from more than one VNC client. I tried this and fired up
more than one client. You can see the same thing happen in all clients.

WARNING: I’ve been told that if you connect to the VNC server from within a VNC Client, you will hang the system.

14 thoughts on “VNC – allowing remote access to graphical desktops”

  1. I tried to start up an ethereal session as root from within
    a vnc window running on FreeBSD 4.6-STABLE and it fails.

    fastpc# ethereal &
    [1] 2858
    fastpc# Xlib: connection to ":1.0" refused by server
    Xlib: Invalid MIT-MAGIC-COOKIE-1 key

    Gtk-WARNING **: cannot open display: :1.0

    [1] Exit 1 ethereal

    Running ethereal as a normal user works fine.

    Has anyone else experienced this?


    1. VNC rocks.
      I use it to manage my EnTee servers via my wide-area local network (i vpn’d los angeles—>san diego<—orange county).

      If i need to hit a server over the internet, i can open the appropriate ports on the network’s router and add map to the server i want to control. i close the hole when i’m done, as VNC only uses 1 pass phrase (no user/password combo).

      And all this from my *nix!
      re: Ethereal – i haven’t tried to reproduce your issue, but you may be able to tcpdump to a file then examine the results.

      Kudos to Dan for the quick’n’dirty on VNC.

    2. Any time I have a problem with VNC it usually boils down to the screen resolution changing on the other machine and VNC crashing as a result of it. I’ve had this problem in both VNC and TightVNC. – The solution is just to restart VNC and you will pick up where you left off.

      I imaging that the script that you placed in your original message is suggesting that there are bigger problems than a client just shutting down on you though. … If so then you might try emailing the wonderful folks at AT&T Laboritories Cambridge.

      – Tim

  2. Do you have any reason to prefer tightvnc to vnc?

    I followed your article and found vnc to be very useful, but
    I am wondering why there are two different *vnc’s in the ports.

    Any comments?


    1. Yes, tightvnc is a better server depending on your circumstances. But the article doesn’t mention where tightvnc is better than normal vnc.

      Firstly, tightvnc includes JPEG compression. This makes a huge difference if you’re viewing a remote desktop over, say, a 56k dialup. The difference was astounding enough for me to be able to use a 1024x768x32bpp at a superb speed.

      Under *nix-type systems, you can enable the "tight" encoding from the viewer command line. I’m not a Windows user, so I can’t tell you where it is in the GUI version, but from the commandline:

      $ xvncviewer -encodings tight -quality 0 <hostname:port>
      This will produce noticeable JPEG compression artifacts, but your session will be faster if you’re over a low-bandwidth network.

      There is, lastly, one more VNC in the pipeline. Tridia VNC ( supplies a server with the "tight" encoding for low-bandwidth networks, and also wraps the connection in an SSL tunnel, so you get the benefit of an encrypted connection as well. Worth a look at.

      Oh, and whilst you’re playing with VNC, take a look at krfb ( I don’t know if it’s reached FreeBSD ports, but it’s definately got prospects. Being able to use a proper XFree86-accelerated desktop locally, and still be able walk away and pick up that same session remotely has great benefits.

    2. I usally just create an sshtunnel from whereever i am at the time with compression enabled and then run tightvnc server at home.
      Connection at home is 2.5/0.7 so i just disable compression in the vnc and live with the sshtunnel compression this works great for me..

      Oviously you could go with sshtunnel comperssion + tightvnc comperssion + jpeg if you like to dont know if this help that much tough, i feel a slight "lag" when i tried with all that so i just stick to my sshtunnel 🙂

  3. It’s a question of time and it is some kind of magic on the waves I have been trying vnc lately but I’ve compiled it from a tarball, well what about to make the corrections on the wrapper of the Xvnc that’s it on the vncserver? It’s better or worse to do in this way changing the depth and the geometry or the line that says uname -a? usually it reports errors and it is better to change it to localhost directly, you know not everybuddy has the same gear and VNC is the unique experiment on net that can be made whitout it, ah! usually people changes the localhost in your /etc/rc.conf and writes a fancy name, a solution can be done changing the line uname by localhost. I’ve tryed depth 24 and it works very well except if I use svncviewer it only admits a depth of 8 what I surmise that is due to the SVGAlib. 😉 Ximo

  4. And the most fun is viewing your FreeBSD desktop on windows, and then running vncviewer from X and viewing your windows desktop…the picture goes ad infinitum(er, rather, till the last pixel in the corner).

    Amazingly, this didn’t crash anything or even use a massive amount of bandwidth(compared to normal vnc use.)

  5. Why not install an X-Server on your local windows server, use SSH to FreeBSD server and export the Display? How does this differ than TightVNC? Not to say this isn’t a correct way just wondering on alternatives, i’m new to the BSD world and learned how to export applications including KDE.

  6. Just a warning to those that don’t already know X as I didn’t. The TightVNC port doesn’t list the XFree86-4-clients as a dependancy but it is in that xauth which is needed for passwords and so on, is supplied by this port.


    1. Oh, something else, you just have to love FreeBSD! I got this running on my pitifull box. My FreeBSD box is a p75 with 16mb of ram. Show me a redhat box that will even install on 16mb 😉 Now, I do have more memory to put into this machine, but not going to till I have no other choice but to reboot given my beaut of an uptime 🙂

      root@dimensions:/usr/X11R6/bin# uptime
      9:49AM up 279 days, 6:47, 4 users, load averages: 0.01, 0.08, 0.18

Leave a Comment

Scroll to Top