This is a How-to for Remote Desktop Sharing.
Introduction
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'.
Prerequisites
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.
Linux
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.
Linux
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
Documentation
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 10.1.1.3 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
paul@PAULS-Klikit:/var/lib/debfoster$
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
paul04@paulArtistX:~$
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?
Addendum.
Published in June 27th, 2007
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 127.0.0.1::5900. 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
Client
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
Node
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.
Server
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:
http://www.nomachine.com/ar/view.php?ar_id=AR01C00126
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:
http://www.nomachine.com/download-manager.php
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.
Documentation
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:
http://www.nomachine.com/documentation/admin-guide.php
The NoMachine Team.
NX> 700 Bye.
root@paulArtistX:/home/paul04/Downloads/DownloadedInstallationFiles/NoMachine#
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:
http://www.nomachine.com/documents/server/install.php
- 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
Or:
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:
/usr/NX/share/keys
Distribute the private key from the newly generated couple of keys located in the file:
/usr/NX/share/keys/default.id_dsa.key
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:
/usr/NX/share/keys
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:
/usr/NX/share/keys/default.id_dsa.key
to:
/usr/NX/share/keys/server.id_dsa.key
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:
http://www.nomachine.com/ar/view.php?ar_id=AR02C00150
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.