In order to remotely control the desktop, I needed to setup some sort of secure environment. We all know that VNC by default is not secure. RDP (Remote Desktop Protocol), mainly used for accessing Windows machines, also has it's flaws. I started looking into VNC (Virtual Network Computing) over SSH (Secure Shell) tunneling. My client computer (laptop) is Ubuntu 13.04 and the server I wish to connect to is Xubuntu 13.04. Please do note that since I'm using Xubuntu, the following instructions may not work for you if you don't use lightdm as a window manager.
- Start by installing ssh server on the remote machine:
- sudo apt-get install openssh-server
- If you are using Webmin to configure your system (highly recommended, see here), it is a fairly simple setup after the install completes. The default setup will work for now, but we need to lock it down. More on that in a second.
- If you are running Ubuntu on your local machine, you already have the openssh client installed by default. I cannot speak for Windows, OS X, or other flavors of Linux, but finding a package should be pretty simple using the great interwebs.
- In the terminal on your client computer (ie your laptop), generate ssh public and private keys:
- mkdir ~/.ssh
- chmod 700 ~/.ssh
- ssh-keygen -t rsa
- You will be prompted for a location to save the keys, and a passphrase for the keys. This passphrase will protect your private key while it's stored on the hard drive and be required to use the keys every time you need to login to a key-based system.
- If you do not wish to password-protect your key file (not recommended), just press enter without typing a password. Remember, if your laptop is ever stolen, a brute force attempt may be made to unlock your key file, and then the server you connect to can be compromised.
- Note: Public keys are what you give out to servers. It is what is used in conjunction with your private key - stored locally - to authenticate. Under no circumstances should you give out your private key!
- Now that you have generated your public and private SSH keys, it's time to transfer your public key to the server:
- ssh-copy-id [email protected]
- Replace username with the username you login with on the server. Use the server's local IP address (assuming you're doing this over a LAN) as the host.
- When prompted for the password, enter the password associated with the username you provided for that machine.
- For more details on steps 4 and 5 above, jump on over to SSH Keys on the Ubuntu Community website.
- Great! You're on your way to having a secure shell environment that's actually secure. Now, we must proceed with locking down openssh-server:
- In Webmin, login to the server and find the SSH Server section.
- If you find that SSH Server is in the "Unused" section, click Refresh Modules on the left, bottom. Now logout and log back in. You will now find it under the "Servers" section.
- Allow authentication by password? No
- Permit logins with empty passwords? No
- Allow login by root? No
- Allow RSA (SSH 1) authentication? No
- Allow DSA (SSH 2) authentication? No
- Check permissions on key files? Yes
- Display /etc/motd at login? No
- Ignore users' known_hosts files? No
- User authorized keys file: Default
- Maximum login attempts per connection: 2
- Ignore .rhosts files? Yes
- Listen on addresses: All addresses
- If you have a dedicated IP address for your client, setting this to it's IP would make it even more secure, allowing only connections within the local network.
- Listen on port: 22
- 22 is the default port for SSH. If you wish to change this for more security, connecting will become more difficult.
- Accept protocols: SSH v2
- With modern SSH clients there is no need to enable v1. In fact, there are known vulnerabilities in older SSH servers, including a CRC32 Compensation Attack.
- Disconnect if client has crash? Yes
- Time to wait for login? 120 seconds
- Allow TCP fowarding? Yes
- This sounded insecure to me at first. But, after further research, it actually encapsulates any traffic based on TCP into the SSH tunnel, making insecure traffic (checking mail, surfing the web) secure. However, if you're a LAN admin and have other security restrictions in place for network traffic, enabling TCP forwarding would allow one to bypass those restrictions.
- Allow connection to forwarded ports? No
- Client-Host Options:
- If you have not tweaked this section before, the only available option will be All Hosts
- Click the Add options for client host link at the bottom.
- Enter the host name or IP address of the server
- "*" can be used for host names. ie *.foo.com will allow SSH to anything on the foo.com domain.
- Compression level: Worst
- Setting it to anything else will consume unneeded CPU cycles on a fast network and actually slow down file transfers when using scp
- Use privileged source port? No
- By default SSH clients will use the privileged source port when connecting, which indicates to the server that it is a trusted program and thus can be relied on to provide correct information about the user running it. This is necessary for rlogin-style authentication to work, but unfortunately many networks have their firewalls configured to block connections with privileged source ports, which completely blocks SSH. To have the clients use a normal port instead, select No for the Use privileged source ports? field. Unless you are using host-based authentication, this will cause no harm.
- All other options can be left as default.
- Access Control:
- Select the users you want to allow to connect, or type them in using commas to separate. "?" can be used as a wildcard. ie admin_? will allow any users starting with admin_ to connect.
- Once you have made all of these changes, Stop Server and Start Server from the module's index page to apply the changes.
- SSH-server is now configured and locked down using Webmin, you have generated and published your keys from the client to the server, and are ready to move on to configuring VNC over SSH. But first we must verify that all the changes just made didn't break our SSH connection
- ssh [email protected]
- You will be prompted with something like:
- The authenticity of host '10.0.X.XX (10.0.X.XX)' can't be established.
ECDSA key fingerprint is XX:XX...XX.XX.
Are you sure you want to continue connecting (yes/no)?
- Note: Don't panic! You are connecting to an "unknown" server using only your key for the first time. Unless some hacker is really efficient at setting up a man-in-the-middle attack on your server between the time you installed the ssh-server to now, you are most likely connecting to what you intended to connect to.
- Type yes
- Warning: Permanently added '10.0.X.XX' (ECDSA) to the list of known hosts.
Permission denied (publickey).
- I didn't expect this error. Upon exiting and logging in again, all was well with the world and I did not receive the same error.
- Once you have established a connection successfully, we can move on. Type exit and execute until you are cleared away from the SSH session.
- We will log back into the remote shell, but this time we will use trusted X11 forwarding (-Y option) in order to use a graphical text editor.
- ssh -Y [email protected]
- x11vnc -storepasswd
- Enter a secure password, and again to verify it.
- Store this password as /etc/x11vnc.pass (not the default location)
- sudo chmod 744 /etc/xllvnc.pass
- cd /etc/lightdm
- sudo gedit lightdm.conf
- Assuming gedit is installed on your machine. If not, use whatever text editor is installed, or vi if you are comfortable with that.
- Append the last line to your file, so that it looks like this:
- Save and close
- Note: If this step were skipped, x11vnc will not start after rebooting your server and must be manually started after logging in locally. Some may wish to do this as an extra layer of security.
- sudo service lightdm restart
- Now the service is running and will run each time your computer starts.
- Back on your local computer (outside the SSH session), you will want to bring the remote display to you:
- Install SSVNC from the Ubuntu software center for your local VNC viewer.
- In the VNC Host:Display field:
- Assuming you have not encountered any errors - as I did while writing this - you should be viewing your server remotely!
- To stretch / shrink the display:
- F8 > Scale Viewer > auto or fit depending on your preference.
- Full screen view:
- To close the remote viewer but leave you logged in on the server, simply close the window. If you wish to log out, do that normally as well.