Computing Tidbits

This guide illustrates the concepts for tunneling VNC over SSH. VNC is a protocol that allows you to control a desktop from a remote computer and allows others to view or control your desktop from their computer. However, using VNC alone can be a security risk. Although VNC uses password encryption, the rest of the traffic is sent unencrypted.

SSH or Secure Shell, is a secure protocol with a feature called port forwarding that can be used to provide secure connections for VNC, as well as for POP3, SMTP, RDP, HTTP and other protocols. Using SSH port forwarding to secure connections is also known as SSH Tunneling. SSH tunneling creates a SSH tunnel to encapsulate unencrypted traffic (the payload protocol), such as VNC, over an encrypted SSH channel (the delivery protocol). In other words, using VNC with SSH port forwarding makes a port from one PC appear on another PC through a SSH connection, providing a secure path for the VNC traffic.

A practical use of SSH tunneling with local and remote port forwarding would be to securely exchange the desktops between two PCs using the VNC protocol. Setting up the SSH sessions can be accomplished for both PCs from the same SSH client PC. Another use for SSH tunneling not covered in this guide is to bypass firewalls that block certain ports, such as port 80, which are often blocked to prevent users from accessing the Internet using company computers (see related article – Using SSH to secure Internet connections).

SSH Port Forwarding Summary

In the following definitions and examples, a remote machine is defined as the PC with the SSH server. All commands in the examples here are executed from the SSH client machine (192.168.1.1). Although both forwarded and local ports may be the same, the examples shown use different port numbers for clarification.

Two types of SSH port forwarding are: (1) local port forwarding, and (2) remote port forwarding, with local port forwarding being the more common. Another type of SSH port forwarding not covered in this guide, is Dynamic port forwarding (see Using SSH to secure Internet connections).

1.  Local port forwarding –  A port from the client PC is forwarded to the remote PC. A connection to this port enables data to be sent bidirectionally over the SSH connection between the client and remote PC. See Fig 1.

2. Remote port forwarding – This is a reverse of local port forwarding.  A port from the remote PC is forwarded to the client PC.  A connection to this port enables data to be sent bidirectionally over the SSH connection between the client and remote PC. See Fig 2.

Other points:

• Ports may be forwarded to multiple hosts on a single connection or by using multiple SSH connections.
• Other computers on the Internet are prevented from connecting to forwarded ports unless enabled with the “-g” flag.
• VNC servers must allow loopback connections since clients are seen as local connections.
• To connect PCs over the Internet, port 22 must be forwarded for SSH on the router.
• Port numbers from 0 to 1023 are privileged ports used by system processes to provide network services. For Unix and Unix-like operating systems, these processes can only execute with superuser privileges. It’s therefore best to avoid using ports under 1024 for local ports.

Local Port Forwarding for VNC

Figure 1 illustrates local port forwarding for a VNC session (click to enlarge) over a LAN. The client Windows PC has IP address 192.168.1.1 and the remote Linux PC has IP address 192.168.1.3.  The syntax for local port forwarding as used in this example:

ssh username@serverhost -L localport:host:remoteport

Note: The use of a Windows PC and Linux machine in the Figure 1 below is for illustration purposes only. The operating systems are irrelevant. What matters is that client PC has a SSH client and VNC viewer, and the remote machine has a SSH server and VNC server. 

To establish the SSH connection using local port forwarding, the following command can be entered into a command window on the client PC:

ssh user@192.168.1.3 -L 6999:localhost:5901

• user@192.168.1.3 = SSH host to connect to
• -L = Option to enable local port forwarding
• 6999 = Port on the client PC
• localhost = Host server to connect to (the remote PC, same as 127.0.0.1)
• 5901 = Port on the remote host (forwarded from the client PC)

To connect to the VNC server, enter the following into the VNC viewer:

127.0.0.1:6999

or

localhost:6999

Remote Port Fowarding for VNC

Figure 2 illustrates remote port forwarding for a VNC session (click to enlarge) over a LAN. The client Windows PC has IP address 192.168.1.1 and the remote Linux PC has IP address 192.168.1.3. The syntax for remote port forwarding as used in this example:

ssh username@serverhost -R localport:host:remoteport

Note: The use of a Windows PC and Linux machine in the Figure 1 below is for illustration purposes only. The operating systems are irrelevant. What matters is that the the client PC has a SSH client and VNC server, and the remote PC has a SSH server and VNC viewer. 

To establish the SSH connection using remote port forwarding, the following command could be entered into a command window on the client PC:

ssh user@192.168.1.3 -R 6999:localhost:5901

• user@192.168.1.3 = SSH host to connect to
• -R = Option to enable remote port forwarding
• 6999 =Port on the remote host
• localhost = Host server to connect to (the client PC, same as 127.0.0.1)
• 5901 = Port on client PC (forwarded from the remote PC)

(Add the “-v” option at the end of the command above to view debugging messages about SSH’s connection progress)

To connect to the VNC server, enter the following into the VNC viewer:

127.0.0.1:6999

or

localhost:6999

This guide demonstrates how to setup OpenSSH RSA public-key authentication for Windows (using OpenSSH v3.8.1p1-1) and Linux (using OpenSSH v5.3p1) PCs currently working with password authentication on a local network. Although the information for this guide was tested on PCs with WinXP and Lubuntu, it can be applicable for other versions of Linux and Windows. You will need physical access to both PCs.

Public-key Cryptography

Public-key cryptography uses of a pair of matching keys, a public key and a private key, which are created at the same time using a key generation utility (ssh-keygen.exe is the key generation utility used in OpenSSH). A public key can be known to anyone and is used to encrypt data. The only way to decrypt data encrypted with the public key is with the matching private key. Although the two keys are related, a private key can’t be created from its matching public key. Public-key cryptography is widely used for public-key authentication to enable secure logins to servers without passwords, and for digital or electronic signatures, which certifies the authenticity of data signed by the private key.

OpenSSH Public-key Authentication

OpenSSH can use either the RSA or DSA algorithms for public-key authentication. RSA stands for stands for Rivest, Shamir and Adleman, the last names of the MIT team members who developed it. DSA stands for Digital Signature Algorithm, a US Government standard proposed by the National Institute of Standards and Technology. Although there are arguments for and against using one or the other, RSA is often the preferred choice because of its verification speed and key strength. See What is better for GPG keys – RSA or DSA? for a discussion on on this topic.

The importance for using pubic key authentication can be summed up in this statement from the Ubuntu help pages: “If your SSH server is visible over the Internet, you should use public key authentication instead of passwords if at all possible. If you don’t think it’s important, try logging all of the malicious login attempts you get for the next week. My computer – a perfectly ordinary desktop PC – had over 4,000 attempts to guess my password and almost 2,500 break-in attempts in the last week alone. “

Steps for RSA Public-key Authentication

The following steps will setup RSA public-key authentication keys without a passphrase to enable automatic logins between Linux to Windows PCs on a local network. The instructions will be similar to setup public-key authentication on remote hosts, except that SSH port 22 (if using the default port) must be forwarded to access remote servers from behind a router. When creating keys without a passphrase, as in this guide, make sure to place the public key on trusted hosts as it’s possible to compromise the remote computer should your private key fall into the wrong hands.

From the Windows PC

Step 1 – Generate Public Keys for the Windows PC

On the Windows PC, open a CMD window and type in the following command and hit ENTER to create a RSA key of 2048-bits (the default). The -t option specifies the type of key:

ssh-keygen -t rsa

Note: If you get a command is not recognized error, your path is incorrect. In this case, change to the bin folder where OpenSHH is installed to run the command.

When the command is executed, you will be prompted for a location to save the keys, and then for a passphrase as shown below. Hit ENTER to accept the default locations and to set NO passphrase.

Output:

Generating public/private rsa key pair
Enter file in which to save the key (/home/username/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/username/.ssh/id_rsa
Your public key has been saved in /home/username/.ssh/id_rsa.pub

The public key will be saved as .ssh/id_rsa.pub and your private key saved as .ssh/id_rsa in your home folder. The home directory is setup for users when OpenSSH was installed and configured.

Step 2 – Transfer Public Key to Linux PC

For the public key to be usable, it must be appended to the .ssh/authorized_keys file on the Linux computer and/or on other hosts you log into. If the authorized_keys file does not exist in your Linux computer’s home .ssh directory, create it. The public key (ending in .pub) can be copied to /home/username/.ssh/otherkeys on the Linux computer using a USB drive, another medium, Windows file sharing, or SCP. Make sure to only copy the key and not move it.

After transferring the public key, at the Linux PC, open a terminal window and navigate to the .ssh folder in your home directory, and append the public key using the command below:

cat otherkeys/id_rsa.pub >> authorized_keys

Note: the key can also be cut and pasted into the authorized_keys file using a text editor

OR – copying the key if the authorized_keys file is empty or not present

To remotely copy the public key to the Linux PC using SCP, enter the following in a command window. Note that there is no command for appending to a file using SCP. You will be asked for your password to use SCP remotely from the Windows PC:

# scp ~/.ssh/id_rsa.pub user@192.168.x.x:.ssh/authorized_keys

Step 3 – Edit sshd_config

Open a command window and try to authenticate automatically to the Linux PC from the Windows PC using SSH. Make sure the SSH server was started on the Linux PC. It should work. If not, continue with the rest of this step and then recheck.

To troubleshoot the SSH public-key cryptography authentication processes, you can use the verbose option switch (-v) in the ssh command when logging in:

ssh -v user@192.168.x.x

If authentication didn’t work, goto the Linux PC and check that the permissions of the .ssh directory are set to octal 700. If not, use the following command from the Linux PC to change it:

# chmod 700 ~/.ssh/authorized_keys

If error messages were observed relating to the known_hosts file, find and delete the entries in the known_hosts file in the user .ssh directory of the Windows PC.  The entries causing the errors will be numbered in the error message. After deleting the offending entry in the known_hosts file, test again to determine whether you can log onto the Linux PC without using a password.

After verifying you can log into the Linux PC without using a password, password authentication will still work should RSA not work for any reason, which is a security vulnerability. Password authentication can be turned off completely by changing the following entries in the etc/ssh/sshd_config file on the Linux PC. To use RSA authentication exclusively, make the following changes to the sshd_config to force public-key authentication and disable password authentication:

PasswordAuthentication no
PubkeyAuthentication yes
RSAAuthentication yes

After saving the file, restart the Linux PC SSH server using sudo /etc/init.d/ssh restart from a terminal on the Linux PC before logging in.

____________________________________________________________________________________

From the Linux PC

The steps are essentially the same as the previous steps with a few minor differences from the previous instructions

Step 1 – Generate Public Keys for the Linux Computer

From the Linux PC, open a terminal and type in the following command and hit ENTER to create a RSA key of 2048-bits (the default). The -t option specifies the type of key:

ssh-keygen -t rsa

When the command is executed, you will be prompted for a location to save the keys, and then for a passphrase as shown below. Hit ENTER to accept the default locations and to set NO passphrase.

Output:

Generating public/private rsa key pair
Enter file in which to save the key (/home/username/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/username/.ssh/id_rsa
Your public key has been saved in /home/username/.ssh/id_rsa.pub

The public key will be saved as .ssh/id_rsa.pub and your private key saved as .ssh/id_rsa in your home folder.

Step 2 – Transfer Public Key to Windows PC

For the public key to be usable, it must be appended to the .ssh/authorized_keys file on the Windows computer, other Linux PCs, and/or other hosts you log into. If the authorized_keys file does not exist in the user’s Windows .ssh directory, create it. The public key (ending in .pub) can be copied to \home\username\.ssh\otherkeys on the Windows computer using a USB drive, another medium, file sharing, or SCP. Make sure to only copy the key and not move it.

After transferring the public key, at the Windows PC, navigate to the .ssh folder in your home directory, and append the public key to the authorized_keys file using the command below:

copy /b authorized_keys + otherkeys\id_rsa.pub authorized_keys

Note: the key can also be cut and pasted into the authorized_keys file using a text editor

OR – if the authorized_keys file is empty or not present

To remotely copy the public key from the Linux PC to the Windows PC with SCP, enter the following in a terminal window. Note that there is no command for appending to a file using SCP. You will be asked for your password to use SCP remotely from the Linux PC:

# scp ~/.ssh/id_rsa.pub user@192.168.x.x:.ssh/authorized_keys

Step 3 – Edit sshd_config

In a terminal window try to log into the Windows PC with public-key authentication using SSH. Make sure the SSH server was started on the Windows PC. It should work. If not, continue with the rest of this step and then recheck.

To troubleshoot the SSH public-key cryptography authentication processes, you can use the verbose option switch (-v) in the ssh command as follows when logging in:

ssh -v user@192.168.x.x

If error messages errors were observed relating to the known_hosts file, find and delete those entries in the known_hosts file in the user .ssh directory in the Linux PC before continuing. The entries causing the errors will be numbered in the error message.

After deleting the offending entry in the known_hosts file, test again to determine whether you can log onto the Windows PC without using a password.

After verifying you can log into the Windows PC without using a password, password authentication will still work should RSA not work for any reason, which is also a security vulnerability. Password authentication can be turned off completely by changing the following entries in the OpenSSH\etc\sshd_config file on the Windows PC. To use RSA authentication exclusively, make the following changes to the sshd_config file to force public-key authentication and disable password authentication:

Note: If you still are unable to log in with pubic-key authentication at this point, do not make the following changes to the sshd_config file to force public-key authentication since you may need to login locally using your password with tools such as WinSCP. See below troubleshooting procedures:

StrictModes no
PasswordAuthentication no
PubkeyAuthentication yes
RSAAuthentication yes

After saving the sshd_config file, restart the Windows PC SSH server first by stopping it using net stop opensshd and then restarting it using net start opensshd in a command window on the Windows PC to allow the config file to take effect before logging in.

If public-key authentication still doesn’t work, the most likely cause is that that the read/write/access permissions for the .ssh directory or for OpenSSH for the Windows PC are incorrect. See the below troubleshooting procedures below for further information.

Troubleshooting Windows OpenSSH server issues:

File permissions issues are a notorious problem for getting pubic-key authentication to work for OpenSSH on Windows. It’s probably the most confusing and most difficult issue to resolve. After much research and troubleshooting, I got it to work following this source from osdir.com. However, it’s uncertain whether it was one, all, or a combination of the suggestions that fixed the problem. In any case, below is a summary of the suggestions and how they were followed.

The tool used to change file permissions for the instructions below was WinSCP, with 127.0.0.1 as the host name and SFTP as the protocol (see screenshot below).

Permission changes were made using the properties window as shown in the screenshot below:

Here are the suggestions from osdir.com and how each was followed. Suggestions are preceded by an asterisk “*” and how the suggestions were followed are in bold :

*Change ownership of OpenSSH folder/subfolders to Administrators using Windows Explorer – Performed this for the folder and all subfolders using WinSCP.

*Grant Administrators full control of the OpenSSH folder – Same as above using Octal 0700

*From a command prompt, type “cacls c:\program files\openssh /t /e /c /g Administrators:F” * – Performed this for the c:\ssh folder, which was the OpenSSH folder on my PC.

Edit sshd_config file and set StrictModes to “no” –  Changed the StrictModes entry to “no” and saved the file

*Under the user’s profile, grant Administrators (and only Administrators) full control of the .ssh folder and files – Did this for all folders and files for .ssh in the user directory (C:\Documents and Settings\user\.ssh).

*If this folder does not exist, it can be created by establishing an SSH connection to another box – Skipped. The .ssh file already existed

*On clients only, copy the private RSA key to the local .ssh folder and name it “id_rsa” - Skipped. The private keys already existed.

*Copy the client’s public RSA key to the desired server(s) by adding it to an “authorized_keys” text file located under the server’s .ssh folder - Skipped. Done previously.

* To use publickey authentication, use the SSH command line switch “-o PreferredAuthentications=publickey”. Alternately, you can modify the ssh_config file to make this the default – Skipped.

If the above instructions worked:

Decide whether to use RSA authentication exclusively. If so, edit the sshd_config file per the instructions above.

Note: many instructions on various web sites suggest copying public keys to the user’s .ssh directory on the server. If you do, make sure to place them in a separate folder such as a otherkeys folder or another name such as username_key since existing public keys (id_rsa.pub) will be overwritten if multiple PCs are used to access the same machine. 

VNC is one of many protocols used to share desktops between Linux and Windows PCs (see this Wikipedia entry for a comparison of various remote desktop software packages). Although a number of VNC (Virtual Network Computing) servers include some type of built-in encryption, many do not. In addition, many VNC client/viewers tend to be basic so they generally don’t include any built-in encryption support. For both aforementioned situations, SSH tunneling can be used to secure sessions between VNC servers and even the most basic VNC client/viewers, regardless of any built-in protocols. However, using SSH to encrypt VNC communications can be a manually intensive and multi-step process requiring starting up SSH and VNC servers and configuring SSH and VNC clients for local or remote port forwarding.

An Enhanced TightVNC Viewer, SSVNC, is free multi-platform SSH/SSL VNC viewer that automates this process. It’s also compatible with a wide range of VNC servers. In fact, the SSVNC web site states that SSVNC works with nearly any VNC Server host running SSHD and those running an SSL tunnel, including VeNCrypt SSL/TLS and Vino/ANONTLS encryption extensions to VNC on Unix, Mac OS X, and Windows. SSVNC also works as a regular VNC viewer without encryption as well. SSVNC is available from the Ubuntu repositories and installable through the Synaptic Package Manager or apt-get, while Unix, MacOS, and Windows versions are available from the SSVNC web site and through Sourceforge.net.

For this post, SSVNC (using the precompiled binaries) was tested on a Windows XP machine connected to TightVNC and X11VNC servers running on a Lubuntu machine and SSH tunneling enabled through the SSVNC viewer. Although this viewer is packed with features, it worked quickly and easily. Its many features are listed on the SSVNC web site.

Related Information:

VNC on Linux