Chapter 19. Remote Access with SSH, Telnet, and VNC
In This Chapter
Controlling your system remotely is one of the cooler things you can do with Ubuntu: With just a bit of configuration, you can connect from any Linux box to another computer in a variety of ways. If you just want to check something quickly or if you have limited bandwidth, you have the option of using only the command line, but you can also connect directly to the X server and get full graphical control.
Understanding the selection of tools available is largely a history lesson. For example, Telnet was an earlier way of connecting to another computer through the command line, but that has since been superseded by Secure Shell (SSH). That is not to say that you should ignore Telnet; you need to know how to use it so you have it as a fallback. However, SSH is preferred because it is more secure. We cover both in this chapter.
Setting Up a Telnet Server
Telnet is an older service. The client is part of the default installation, but is not activated by default. The server is not part of the default installation. This is because everything Telnet transmits and receives is in plain text, including passwords and other sensitive information. Telnet is generally not a good choice for communication. However, you might want to install Telnet for certain situations, such as connecting to a piece of equipment that doesn’t have SSH available, such as embedded systems where having a small OS footprint is important and more secure methods of communication are not available. In addition, sometimes Telnet is the quickest and easiest way to test newly installed services during configuration, such as a Postfix mail server. You might also want to install Telnet to learn about it and test it, simply because you might run across moments in the real world where no other option exists.
If you decide to install Telnet, use Synaptic or apt to install telnetd, which installs the server.
Start by configuring your firewall to allow connections through port 23. If this port is blocked, you cannot use Telnet. See Chapter 20, “Securing Your Machines,” for help doing this.
After making any needed configuration adjustments to your firewall, type telnet your IP to test to confirm both the client and server are installed and working by connecting from your terminal using the client back to the server running on your own computer. You are prompted to enter your username and password. The whole conversation should look something like this:
matthew@seymour:~$ telnet 192.168.1.102
Trying 192.168.1.102...
Connected to 192.168.1.102 (192.168.1.102)
Escape character is "^]".
Welcome to babbage
Ubuntu 12.04 LTS
* All access is logged *
login: matthew
Password:
Last login: Sun Jul 4 10:08:34 2012 from seymour
matthew@babbage~$
Tip
The server responds with Welcome to babbage, Ubuntu 12.04 LTS, which is a customized message. Your machine will respond similarly. This might not be secure: Giving away version numbers is often not a smart move on a machine that might be accessed from outside of a secure network as it can narrow down the options for an attacker to use. In fact, even saying Ubuntu might be questionable for the same reason. For those instances where you want to take an extra step in obscuring your information, you can edit the issue and issue.net files in your /etc directory to change the message displayed.
To use Telnet to connect to a different computer, use that computer’s IP address on the network instead of using your own. You can use Telnet on local networks and across the Internet to connect to any computer running the server on an open port.
Telnet uses port 23, but you can use it with other ports by adding the port to the IP address, as in this example where we use it to connect to port 110 to test a POP3 connection/server:
matthew@seymour:~$ telnet 192.168.1.102 110.
Telnet Versus SSH
Although Telnet is worth keeping around as a fail-safe, last-resort option, SSH is superior in nearly every way. Telnet is fast but also unsecure. As stated earlier, it sends all your text, including your password, in plain text that can be read by anyone with the right tools. SSH, on the other hand, encrypts all your communication and so is more resource intensive but secure—even a government security agency sniffing your packets for some reason would still have a hard time cracking the encryption.
Andy Green, posting to the fedora-list mailing list, summed up the Telnet situation perfectly when he said, “As Telnet is universally acknowledged to encourage evil, the service telnetd is not enabled by default.” It is worthwhile taking the hint: Use Telnet as a last resort only.
Setting Up an SSH Server
If not installed already, you can install the OpenSSH server by adding the openssh-server package. As you might have guessed, sshd is the name for the SSH server daemon.
Start by configuring your firewall to allow connections through port 22. If this port is blocked, you cannot use SSH. See Chapter 20, “Securing Your Machines,” for help doing this.
Two different versions of SSH exist, SSH1 and SSH2. The latter is newer and more secure, comes with more features, and is the default in Ubuntu. Support for SSH1 clients is best left disabled so that older clients cannot connect. This is done by default in the /etc/ssh/sshd_config file on this line:
Protocol 2
If you have no other option and absolutely have to allow an older client to connect, add a new line:
Protocol 1
SSH Tools
To the surprise of many, OpenSSH actually is comprised of a suite of tools. We have already seen ssh, the Secure Shell command that connects to other machines, and sshd, the SSH server daemon that accepts incoming SSH connections. However, there is also sftp, a replacement for ftp, scp, and rcp.
You should already be familiar with the ftp command because it is the lowest common denominator system for handling FTP file transfers. Like Telnet, though, ftp is unsecure: It sends your data in plain text across the network, and anyone can sniff your packets to pick out a username and password. The SSH replacement, sftp, puts FTP traffic over an SSH link, thus securing it.
The rcp command might be new to you, largely because it is not used much anymore. Back in its day, rcp was the primary way of copying a single file to another server. As with ftp, scp replaces rcp by simply channeling the data over a secure SSH connection. The difference between sftp and scp is that the former enables you to queue and copy many files simultaneously, whereas the latter is usually used to just send one, although scp can be used with the -r option to send an entire directory at once. See the man page for details.
Using scp to Copy Individual Files Between Machines
The most basic use of the scp command is to copy a file from your current machine to a remote machine. You can do that with the following command:
matthew@seymour:~$ scp test.txt 192.168.1.102:
The first parameter is the name of the file you want to send, and the second is the server to which you want to send it. Note that there is a colon (:) at the end of the IP address. This is where you can specify an exact location for the file to be copied. If you have nothing after the colon, as in the previous example, scp copies the file to your /home directory. As with SSH, scp prompts you for your password before copying takes place.
You can rewrite the previous command so that you copy test.txt from the local machine and save it as newtest.txt on the server:
matthew@seymour:~$ scp test.txt 192.168.1.102:newtest.txt
Alternatively, if there is a directory where you want the file to be saved, you can specify it like this:
matthew@seymour:~$ scp test.txt 192.168.1.102:subdir/stuff/newtest.txt
The three commands so far have all assumed that your username on your local machine is the same as your username on the remote machine. If this is not the case, you need to specify your username before the remote address, as follows:
matthew@seymour:~$ scp test.txt usernamenewtest.txt
You can use scp to copy remote files locally, simply by specifying the remote file as the source and the current directory (.) as the destination:
matthew@seymour:~$ scp 192.168.1.102:remote.txt.
If you want to copy files from one remote machine to another remote machine using scp, the best method is to first ssh to one of the remote machines and then use scp from that location.
Using sftp to Copy Many Files Between Machines
sftp is a mix between ftp and scp. Connecting to the server uses the same syntax as scp—you can just specify an IP address to connect using your current username, or you can specify a username using username@ipaddress. You can optionally add a colon and a directory, as with scp. After you are connected, the commands are the same as ftp: cd, put, mput, get, quit, and so on.
In one of the scp examples, we copied a remote file locally. You can do the same thing with sftp with the following conversation:
matthew@seymour:~$ sftp 192.168.1.102
Connecting to 192.168.1.102...
[email protected]'s password:
sftp> get remote.txt
Fetching /home/matthew/remote.txt to remote.txt
/home/matthew/remote.txt 100% 23 0.0KB/s 00:00
sftp> quit
matthew@seymour:~$
Although FTP remains prominent because of the number of systems that do not have support for SSH, SFTP is gaining in popularity. Apart from the fact that it secures all communications between client and server, SFTP is popular because the initial connection between the client and server is made over port 22 through the sshd daemon. Someone using SFTP connects to the standard sshd daemon, verifies himself, and then is handed over to the SFTP server. The advantage to this is that it reduces the attack vectors because the SFTP server cannot be contacted directly and so cannot be attacked as long as the sshd daemon is secure.
Using ssh-keygen to Enable Key-Based Logins
There is a weak link in the SSH system, and, inevitably, it lies with users. No matter what lengths system administrators go to in training users to be careful with their passwords, monitors around the world have Post-it notes attached to them with pAssw0rd written on them. Sure, it has a mix of letters and numbers, but it can be cracked in less than a second by any brute-force method. Brute-forcing is the method of trying every password possibility, starting with likely words (such as password and variants, or god) and then just trying random letters (for example, a, aa, ab, ac, and so on).
Even very strong passwords are no more than about 16 characters; such passwords take a long time to brute-force but can still be cracked. The solution is to use key-based logins, which generate a unique, 1024-bit private and public key pair for your machine. These keys take even the fastest computers a lifetime to crack, and you can back them up with a password to stop others from using them.
Creating an SSH key is done through the ssh-keygen command, like this:
matthew@seymour:~$ ssh-keygen –t dsa
Press Enter when it prompts you where to save your key, and enter a passphrase when it asks you to. This passphrase is just a password used to protect the key. You can leave it blank if you want to, but doing so would allow other people to use your account to connect to remote machines if they manage to log in as you.
After the key is generated, change the directory to .ssh (cd ~/.ssh), which is a hidden directory where your key is stored and also where it keeps a list of safe SSH hosts. Assuming you use the default options, here you see the files id_dsa and id_dsa.pub. The first is your private key, and you should never give it out. The second is your public key, which is safe for distribution. You need to copy the public key to each server you want to connect to via key-based SSH.
Using scp, you can copy the public key over to your server, like this:
matthew@seymour:~$ scp id_dsa.pub 192.186.1.102:
This places id_dsa.pub in your /home directory (for an account that uses the same username as your local account) on 192.186.1.102. The next step is to ssh into 192.186.1.102 normally and set up that key as an authorized key. So, you can ssh in as yourself:
matthew@seymour:~$ ssh 192.168.1.102
After logging in normally, type this:
matthew@babbage:~$ cat id_dsa.pub >> .ssh/authorized_keys
matthew@babbage:~$ chmod 400 .ssh/authorized_keys
The touch command creates the authorized_keys file (if it does not exist already); then you use cat to append the contents of id_dsa.pub to the list of already authorized keys. Finally, chmod is used to make authorized_keys read-only.
With that done, you can type exit to disconnect from the remote machine and return to your local machine. Then you can try running ssh again. If you are prompted for your passphrase, you have successfully configured key-based authentication.
That is the current machine secured, but what about every other machine? It is still possible to log in from another machine using only a password, which means your remote machine is still vulnerable.
The solution to this is to edit the /etc/ssh/sshd_config file. This requires super user privileges. Look for the PasswordAuthentication line and make sure it reads no (and that it is not commented out with a #). Save the file, and run kill -HUP 'cat /var/run/sshd.pid' to have sshd reread its configuration files. With that done, sshd accepts only connections from clients with authorized keys, which stops crackers from brute-forcing their way in.
Tip
For extra security, you are strongly encouraged to set PermitRootLogin to no in /etc/ssh/sshd_config. When this is set, it becomes impossible to ssh into your machine using the root account—you must connect with a normal user account and then use su or sudo to switch to root. This is advantageous because most brute-force attempts take place on the root account because it is the only account that is guaranteed to exist on a server.
Also, even if a cracker knows your user account, she has to guess both your user password and your root password to take control of your system.
Of course, if you don’t have a root account enabled on your box, this isn’t an issue because it is already impossible to log in directly as root. Hooray for slightly more secure defaults in Ubuntu.
Virtual Network Computing
Everything we have looked at so far has been about remote access using the command line, with no mention so far of how to bring up a graphical user interface (GUI). There are several ways of doing this in Ubuntu, some of which are listed in the “Reference” section later in this chapter. Here we discuss the most popular and the most preferred by the Ubuntu community, which is also the best supported by the developers: Virtual Network Computing (VNC).
VNC is a system for controlling a computer remotely and sharing desktops over a network using a graphical interface. It was created at the Olivetti & Oracle Research Lab, which was acquired by AT&T in 1999 and closed down in 2001. Since then, several of the members of the development team got together to create a free and open-source version of the code (using the GPL), and from that base many different versions have appeared. VNC is widespread in the Linux world and, to a lesser extent, in the Windows world. Its main advantage is its widespread nature: Nearly all Linux distros bundle VNC, and clients are available for a wide selection of platforms.
Start by configuring your firewall to allow connections through port 5900. If this port is blocked, you cannot use VNC.
To set up VNC on your Ubuntu computer to allow others to access your desktop, you only need to tell Ubuntu who should be allowed to connect to your session by searching the Dash for and opening Desktop Sharing. By default, your desktop is not shared. Check Allow Other Users to View Your Desktop to share it. Most likely, you also want to check Allow Other Users to Control Your Desktop; otherwise, people can see what you are doing but not interact with the desktop (which is not very helpful). If you are using this as a remote way to connect to your own desktop or one that is running unattended when you will need access, uncheck You Must Confirm Each Access to This Machine. If you don’t do this, when you try to connect from your remote location, Ubuntu pops up a message box on the local machine asking Should This Person Be Allowed to Connect? Because you are not there to click Yes, the connection fails. If you want to let someone else remotely connect to your system, keep this box enabled so that you know when people are connecting. You should always enter a password, no matter who it is that will connect. The options suggested are shown in Figure 19.1.
To access a computer that is running VNC from your Ubuntu desktop, search the Dash for and run the Remmina Remote Desktop Client. The program starts by searching the local network for shared desktops. If any are found, they are listed. In Figure 19.2, Heather’s computer is shown.
From the screen in Figure 19.2, select an entry and select the Open the connection icon at the top left, in the bar under the title bar with the window controls for close, minimize, and expand to full screen. If you have not yet entered any computers, then select the Create a new connection icon, just next to the first one, to enter the details for a computer you have already set up somewhere to be accessed using VNC as in Figure 19.3.
When you have finished, close the window in which you are viewing the remote desktop.
VNC should not be considered secure over the Internet or on untrusted internal networks.
References
www.telnet.org—Telnet’s home page.
https://help.ubuntu.com/community/SSH—The Ubuntu community documentation for SSH.
www.openssh.com—The home page of the OpenSSH implementation of SSH that Ubuntu uses. It is run by the same team as OpenBSD, a secure BSD-based operating system.
https://help.ubuntu.com/community/VNC—The Ubuntu community documentation for VNC.
www.realvnc.com—The home page of the team that made VNC at AT&T’s Cambridge Research Laboratory. It has since started RealVNC Ltd., a company dedicated to developing and supporting VNC.
www.tightvnc.com—Here you can find an alternative to VNC called TightVNC that has several key advances over the stock VNC release. The most important feature is that TightVNC can use SSH for encryption, guaranteeing security.
https://help.ubuntu.com/community/FreeNX—The Ubuntu community documentation for FreeNX.
www.nomachine.com/—Another alternative to VNC is in the pipeline, called NX. The free implementation, FreeNX, is under heavy development at the time of writing but promises to work much faster than VNC.