• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Finally, you can manage your Google Docs, uploads, and email attachments (plus Dropbox and Slack files) in one convenient place. Claim a free account, and in less than 2 minutes, Dokkio (from the makers of PBworks) can automatically organize your content for you.



Page history last edited by Paul G. Taylor 11 years, 5 months ago

This is a How-to for Remote Desktop Sharing.





For some time now I have wanted to set up a Remote Desktop Sharing connection over the Internet so as more easily be able to help friends and family when they get stuck with a problem on their computer. It needs to be secure, cross-platform, simple at their end to use and free.


As always, there is no problem, no matter how complex, that on close inspection does not become still more complex. This is no exception!


There are some commercial solutions to this probelm and they are more suited to the needs of a commercal help-desk. What I am wanting to do is more infrequent, one at a time and needing to be free. I  am willing to use some free services so long as they are not limited in time. I am already using OpenDNS, for example, and will consider other similar solutions but I prefer that it all be based on FOSS software as a pre-requisite.


Preliminary Considerations.


The system needs to place as little software on the client computer as possible, be as easy to set up there and as easy for the user to understand and use as possible. All this seems to be indicating what is known as 'Reverse Desktop Connection'.




MS Windows XP

1) Not able to run the server on MS systems at present.

2) Download and install the exe file for the client, to log in to remote server on Unix/Linux system.



1) Download and install the .deb files for client, node and server, in that order. All are needed.

2) Run as either client or server.


Setting it  up


MS Windows XP

Simply run the installed client.



1) For security, get another public/private key pair other than the default one installed if going to run as server.

2) Set up server ...



Security considerations


Example sessions




Sites Visited



Zolved www.zolved.com/remote_control Free, FOSS-based service for MS  Windows only.

FreeNX-kNX mail.kde.org/mailman/listinfo/freenx-knx

NoMachine www.nomachine.com/documents.php OpenSouce, freely available NoMachine equivalent.

Most likely candidate at the moment is NoMachine NX. Downloads available from www.nomachine.com/download.php Server software for Solaris and Linux and Client Software for Solaris, Linux and MS  Windows.




 First session on home network : --



NX> 203 NXSSH running with pid: 25906

NX> 285 Enabling check on switch command

NX> 285 Enabling skip of SSH config files

NX> 285 Setting the preferred NX options

ssh: connect to host port 22: Connection refused


What's all this, then? Grrrrrrrrr.



Well I managed to have a 'Guest' sesion, from the Windows XP machine and hosted by 'testdrive.nomachine.com' and ended up in a a Linux session by remote access from within XP!


It was a little slow at times but bearable.


Now to connect up two machines on my home network. These keep getting refused and I think it has to do with setting up an authenticated account, first, which I haven't yet done successfully, as far as I can tell.


Just verified that the installation was successful : --


paul@PAULS-Klikit:/var/lib/debfoster$ sudo  debfoster


nxserver is keeping the following 2 packages installed:

  nxclient nxnode

Keep nxserver? [Ynpsiuqx?], [H]elp: Y



These three applications support each other and are all needed for this method of remote desktop sharing.


Just verified that this has been successfully installed in ArtistX 0.6 : --


paul04@paulArtistX:~$ sudo debfoster

[sudo] password for paul04:


nxserver is keeping the following 2 packages installed:

  nxclient nxnode

Keep nxserver? [Ynpsiuqx?], [H]elp: Y

Keep conky? [Ynpsiuqx?], [H]elp: Y

Keep hddtemp? [Ynpsiuqx?], [H]elp: Y

Keep nautilus-gksu? [Ynpsiuqx?], [H]elp: Y




Still unable to establish a stable connection from my Linux box : --




NXPROXY - Version 3.3.0

Copyright (C) 2001, 2007 NoMachine.

See http://www.nomachine.com/ for more information.

Info: Proxy running in client mode with pid '8623'.

Session: Starting session at 'Sun Jan 11 00:31:56 2009'.

Info: Connection with remote proxy completed.

Info: Using LAN link parameters 1536/24/1/0.

Info: Using pack method 'adaptive-9' with session 'kde'.

Info: Using product 'LESPS/LI08F00001/LESN/LI08F00001'.

Info: Not using NX delta compression.

Info: Not using ZLIB data compression.

Info: Not using ZLIB stream compression.

Info: Not using a persistent cache.

Info: Forwarding X11 connections to display ':0.0'.

Info: Listening to font server connections on port '11192'.

Session: Session started at 'Sun Jan 11 00:31:57 2009'.

Session: Terminating session at 'Sun Jan 11 00:31:57 2009'.

Info: Waiting the cleanup timeout to complete.

Warning: Parent process appears to be dead. Exiting watchdog.


What is that last warning related to? Is my computer too slow for the connection?


Attempting to connect to a Cosmosis-k32 session on my LAN


Distributing the new SSH private key to the clients

Change the ownership and permissions on the authorized_keys file. Depending on which O.S. your NX is running on, you may need to execute:

chown nx:root /usr/NX/home/nx/.ssh/authorized_keys2

chmod 0644 /usr/NX/home/nx/.ssh/authorized_keys2


Well I managed to do all that and distribute the private key to the other computer, but still not getting access. What am I missing?




Remote Access From Windows - X11vnc

Posted by Tom in software, specials
X11vnc is an easy way to remotely access your Linux desktop from another Windows (or Linux) computer. In this post I will explain how to use X11vnc to securely access your Linux computer from Windows. X11vnc is a VNC server. A VNC server sends images of an X display to a client whenever the display changes. The default VNC server for Linux is Xvnc, which creates a virtual X display that is not displayed on a monitor. X11vnc is different from Xvnc because it works with X displays that are used with a real monitor. This is useful because you can connect to your normal desktop and use any applications you have left open. X11vnc is also easier to set up than a VNC server that creates a virtual display. Because VNC is insecure, you should tunnel it through SSH as I will show you here.
  • The first step is installing X11vnc and a SSH server on the computer that you want to be able to connect to.
  • If you want to access your computer from outside your network you will need to forward port 22 to the computer running the SSH server.
  • Also, you will need to know your global IP address so you can connect to it. A service like No-IP can help you with this.
  • The easiest way to set up the tunneling for VNC on Windows is to use PuTTY. PuTTY is a graphical SSH client for Windows.
  • Once the X11vnc server is running, start the TightVNC client. Connect to This address sends the VNC traffic through the encrypted tunnel. Enter the VNC password when prompted and you are done! TightVNC should display what is on the other computer’s monitor and you will have mouse and keyboard control. When you are finished, close TightVNC. The X11vnc server will automatically quit. Then you can exit PuTTY.




Installing NoMachine on ArtistX 0.6 System


paul04@paulArtistX:~/Downloads/DownloadedInstallationFiles/NoMachine$ ls -l

total 17816

-rw------- 1 paul04 paul04  298170 2008-11-20 23:18 admin-guide.pdf                    Admin Guide

-rw------- 1 paul04 paul04  302476 2007-09-13 21:57 install_001.pdf                      Install Node

-rw------- 1 paul04 paul04  252665 2007-09-14 02:28 install_002.pdf                      Install Server

-rw------- 1 paul04 paul04  372455 2007-09-11 19:15 install.pdf                             Install Client

-rw------- 1 paul04 paul04 4385936 2009-01-13 02:49 nxclient_3.3.0-6_i386.deb

-rw------- 1 paul04 paul04 5838990 2009-03-24 05:10 nxnode_3.3.0-17_i386.deb

-rw------- 1 paul04 paul04 6733068 2009-03-24 05:30 nxserver_3.3.0-22_i386.deb

paul04@paulArtistX:~/Downloads/DownloadedInstallationFiles/NoMachine$ echo "110974884b828536e150dde0152c8148 nxclient_3.3.0-6_i386.deb "

110974884b828536e150dde0152c8148 nxclient_3.3.0-6_i386.deb

paul04@paulArtistX:~/Downloads/DownloadedInstallationFiles/NoMachine$ md5sum nxclient_3.3.0-6_i386.deb

110974884b828536e150dde0152c8148  nxclient_3.3.0-6_i386.deb

paul04@paulArtistX:~/Downloads/DownloadedInstallationFiles/NoMachine$ md5sum nxnode_3.3.0-17_i386.deb

69b40e81bd139ce4a7cf4d5e1b33264a  nxnode_3.3.0-17_i386.deb

paul04@paulArtistX:~/Downloads/DownloadedInstallationFiles/NoMachine$ md5sum nxserver_3.3.0-22_i386.deb

be3072c98c6eb5c63f2dd5d2eee9c0f9  nxserver_3.3.0-22_i386.deb

paul04@paulArtistX:~/Downloads/DownloadedInstallationFiles/NoMachine$ Echo "So all these check out OK"

bash: Echo: command not found

paul04@paulArtistX:~/Downloads/DownloadedInstallationFiles/NoMachine$ echo "So all these check out OK"

So all these check out OK


Installing with dpkg



paul04@paulArtistX:~/Downloads/DownloadedInstallationFiles/NoMachine$ sudo su

[sudo] password for paul04:

root@paulArtistX:/home/paul04/Downloads/DownloadedInstallationFiles/NoMachine# dpkg -i nxclient_3.3.0-6_i386.deb

dpkg: status database area is locked by another process

root@paulArtistX:/home/paul04/Downloads/DownloadedInstallationFiles/NoMachine# dpkg -i nxclient_3.3.0-6_i386.deb

Selecting previously deselected package nxclient.

(Reading database ... 394792 files and directories currently installed.)

Unpacking nxclient (from nxclient_3.3.0-6_i386.deb) ...

Setting up nxclient (3.3.0-6) ...

Showing file: /usr/NX/share/documents/client/cups-info


 CUPS Printing Backend


 The NX Client set-up procedure detected that your "IPP CUPS" printing

 backend doesn't allow printing from the NX session. In order to have

 printing support in your NX system, you need to set proper permissions

 on the IPP backend. Please execute:


   chmod 755 /usr/lib/cups/backend/ipp


root@paulArtistX:/home/paul04/Downloads/DownloadedInstallationFiles/NoMachine# chmod 755 /usr/lib/cups/backend/ipp



root@paulArtistX:/home/paul04/Downloads/DownloadedInstallationFiles/NoMachine# dpkg -i nxnode_3.3.0-17_i386.deb

Selecting previously deselected package nxnode.

(Reading database ... 395006 files and directories currently installed.)

Unpacking nxnode (from nxnode_3.3.0-17_i386.deb) ...

Setting up nxnode (3.3.0-17) ...

NX> 700 Starting: install node operation at: Sun Aug 16 23:53:32 2009.

NX> 700 Autodetected system 'debian'.

NX> 700 Install log is '/usr/NX/var/log/install'.

NX> 700 Creating configuration in /usr/NX/etc/node.cfg.

NX> 700 Inspecting local CUPS environment.

NX> 700 Generating CUPS entries in: /usr/NX/etc/node.cfg.

NX> 700 Installation of version: 3.3.0-17 completed.

NX> 700 Bye.



root@paulArtistX:/home/paul04/Downloads/DownloadedInstallationFiles/NoMachine# dpkg -i nxserver_3.3.0-22_i386.deb

Selecting previously deselected package nxserver.

(Reading database ... 395187 files and directories currently installed.)

Unpacking nxserver (from nxserver_3.3.0-22_i386.deb) ...

Setting up nxserver (3.3.0-22) ...

NX> 700 Installing: server at: Sun Aug 16 23:54:07 2009.

NX> 700 Autodetected system: debian.

NX> 700 Install log is: /usr/NX/var/log/install.

NX> 700 Creating configuration file: /usr/NX/etc/server.cfg.

NX> 723 Cannot start NX statistics:

NX> 709 NX statistics are disabled for this server.

NX> 700 Version '3.3.0-22' installation completed.

NX> 700 Showing file: /usr/NX/share/documents/server/install-notices


Server keys


The initial login between client and server happens through a DSA key

pair, i.e. a couple of specially generated cryptographic keys, called

the private key and the public key, which allow you to establish a

secure connection, by means of SSL encryption, between NX client and

NX server.


The public part of the key-pair is provided during the installation

of the server, while the private part of the key-pair is distributed

together with the NX Client. This ensures that each NX client is able

to authenticate to the server and to start the procedure for autho-

rizing the user and negotiating the session.


If you want to create a virtual private network (VPN) instead, you

need to generate a new DSA key-pair and distribute the private part

of the key-pair to those NX clients you want authenticated to the NX

server. More information on how to generate and distribute a new DSA

key-pair is available at: 




Creating Users


NX is configured to allow access from any system user, as long as

valid credentials are given to the user for the SSH login. NX pro-

vides an alternative authorization method, allowing system admin-

istrators to determine which users are given access to the NX fun-

ctionalities. This works by implementing a separation between the

system password and the NX password, so that, for example, it is

possible to forbid remote access to the system by any other means

except via NX and use the NX tools to implement effective accounting

of the system resources used by the user, or to share NX passwords in

an external database.


To activate the NX user and password DBs, you will have to edit the

NX server configuration file by hand or use the NX Server Manager

Web tool available for download on the NoMachine Web site at:




Session Shadowing and Desktop Sharing


The session shadowing functionality allows you to share NX sessions

running on the node. The desktop sharing functionality instead, gives

access to the native display of the X server as if you were in front

of the monitor. By default you can access sessions in interactive mode

and upon authorization of the session owner. You can modify this beha-

viour by tuning the server configuration according to your needs, for

example by allowing access to sessions in view-only mode, or connecting

to either a suspended session or the local display via the Desktop

Manager login window.


Load Balancing


NX Advanced Server provides support for multi-node capabilities and

load balancing. In its current implementation, NX server can only

manage accounts on the host machine, so to grant access to the node

running remotely, you will need to create the user account directly

on the remote node host by issuing the NX node commands as root user.

You will also need to add the NX Server public DSA Key to the node to

allow this server to connect to the node running on the remote host.




For further information on how to manage the configuration of your

NX system, please refer to the System Administrator's Guide available

on the NoMachine Web site at:




The NoMachine Team.



NX> 700 Bye.





Replacing the default SSH keys used by NX with keys generated for your server

To increase the security of a NX server installation administrators have the possibility to replace the default keys used by clients to actually login to NX server with a SSH key generated per-server.

To generate the keys please follow the instructions reported below.

How to generate SSH keys with NX Server version 2.0.0 or higher

  • Login as the 'root' user to the server on which NX server is

    installed. If NX Server is not installed yet, please download it and install it (alongside with the prerequisite 'NX Client' and

    'NX Node' package suited for your platform). You can find

    detailed instructions on how to install the NX Server packages at:


  • Use the nxserver utility to actually generate the new keys

    as reported below:

            /usr/NX/scripts/setup/nxserver --keygen

How to distribute the new SSH keys

  • Change the ownership and permissions on the authorized_keys file.  Depending on which O.S. your NX is running on, you may need to execute:

    chown nx:root /usr/NX/home/nx/.ssh/authorized_keys2

    chmod 0644 /usr/NX/home/nx/.ssh/authorized_keys2


    chown nx:root /usr/NX/home/nx/.ssh/authorized_keys

    chmod 0644 /usr/NX/home/nx/.ssh/authorized_keys

  • Change the ownership and permissions on the following file:

    chown nx:root /usr/NX/home/nx/.ssh/default.id_dsa.pub

    chmod 0644 /usr/NX/home/nx/.ssh/default.id_dsa.pub

  • A part of the key that must be distributed to clients is placed in:


    Distribute the private key from the newly generated couple of keys located in the file:


    to all clients that have to be granted acccess to the specific NX server host.

  • Once the new key has been distributed to clients place it under the subdirectory 'share/keys' of the NX Client installation tree reserved to this purpose. The 'share/keys' subdirectory can be found in the NX Client installation tree according to the following standards:

    On MacOS/X, Linux and Solaris it corresponds to:


    While on Windows (using the default installation settings), it corresponds to:

    C:\Program Files\NX Client for Windows\share\keys

    When the key has been placed in the above location, please use the key management facilities provided by the NX Client GUI:from the 'General' tab of the session configuration window, click on the 'Key' button and choose Import to import the new key by navigating to the appropriate directory above and Save to save your changes.

Additional Notes:

The NX Client GUI facility allow you to import the new private key for the

session you are configuring. If you don't explicitly import any new key,

the default private key distributed together with the NX Client, i.e.

/usr/NX/share/keys/server.id_dsa.key will be used.

  •  Rename the default private key to preserve it.
  •  Rename the new private key from:




             In this way, the new key will be used as the default key for all NX

             sessions (except those sessions that have been previously configured

             to use a specific key).

Note for NX Server Manager configuration

If a new SSH key has been generated, location and file name of the DSA key need to be specified in the NX Server Manager configuration file. Edit the /usr/NX/etc/manager.cfg file and set a proper value for the NXSSHPathIdentity key.

Restoring the default SSH key-pair

Starting from NX Server version 3.3.0, the --keyrestore server command allows to restore the SSH key-pair provided with the server package. The current public key will be moved to default.id_dsa.pub.backup file, while the current private key will be moved to  /usr/NX/share/keys/default.id_dsa.key.backup file. Run the following command to use the default SSH key-pair:

          /usr/NX/bin/nxserver --keyrestore

In order to restore the default SSH key in the client,  use the key management facilities provided by the NX Client GUI: in the 'General' tab of the session configuration window, click on the 'Key' button and choose Default. Click Save to save your changes.

You might like to see also the following article about how the NX login works:


How to generate SSH keys with NX Server version 1.5.0

  • Login as the 'root' user to the server on which NX server is installed.
  • Use the 'nxsetup' utility to actually generate the new keys as reported below:

           /usr/NX/bin/nxsetup --keygen


Remote Secure Shell


As a completely different alternative to 'Desktop Sharing', it is possible to use a 'Secure Shell' remotely, and have full CLI access to a remote machine.


See http://pgtips91.pbworks.com/Secure_Shell_Log-in



Comments (0)

You don't have permission to comment on this page.