In this chapter and the next, we'll look at some of the ways Linux offers to administer a server and access your workstation remotely. Linux gives users great flexibility and functionality. You may have command-line only or a full graphical desktop, just as though you were physically present at the remote machine.
OpenSSH is the tool of choice for remote command-line administration. It's secure, and easy to set up and use. It's also good for running a remote graphical desktop because you can tunnel X Windows securely over SSH. This works well over fast local links. However, it's less satisfactory over a dial-up or Internet connection because you'll experience significant lag.
Rdesktop is a simple Linux client for connecting to Windows Terminal Servers, and to the Windows XP Professional Remote Desktop. This is useful for some system administration tasks, and for accessing Windows applications from Linux.
For dial-up users who want a remote graphical desktop over dial-up, FreeNX is just the ticket. It is designed to deliver good performance over slow links. Currently, you can use it to access a Linux PC from Linux, Windows, Mac OS X, and Solaris.
VNC is the reigning champion of cross-platform remote graphical desktops. With VNC, you can do all sorts of neat things: run several PCs from a single keyboard, mouse, and monitor, mix and match operating systems, and do remote technical support.
In this chapter, we'll look at how to use OpenSSH. The next chapter is devoted to Rdesktop, FreeNX, and VNC.
OpenSSH is the Free Software implementation of the SSH protocol, licensed under a modified BSD license that pretty much lets you do whatever you want with it, including modifying and redistributing it, as long as you include the copyright notices.
OpenSSH is used to foil eavesdropping and spoofing on network traffic by encrypting all traffic during a session, both logins and data transfer. It performs three tasks: authentication, encryption, and guaranteeing the integrity of the data transfer. If something happens to alter your packets, SSH will tell you.
There are two incompatible SSH protocols: SSH-1 and SSH-2. OpenSSH supports both of them, but I do not recommend using SSH-1 at all. If you have to log in to remote systems under someone else's control that are still using SSH-1, consider exercising some tough love and telling them you are not willing to risk your security any more, and they must upgrade. SSH-1 was great in its day, but that was then. It has a number of flaws that are fixed by upgrading to SSH-2. See "CA-2001-35" (http://www.cert.org/advisories/CA-2001-35.html) for more information, and don't forget to review the list of references at the end of the article.
You may use SSH port forwarding, also called tunneling, to securely encapsulate non-secure protocols like wireless and VNC, which you'll see in various recipes in this book.
OpenSSH supports a number of strong encryption algorithms: 3DES, Blowfish, AES, and arcfour. These are unencumbered by patents; in fact, the OpenSSH team has gone to great lengths to ensure that no patented or otherwise encumbered code is inside OpenSSH.
OpenSSH is a suite of remote transfer utilities:
The OpenSSH server daemon.
Stands for secure shell, though it doesn't really include a shell, but provides a secure channel to the command shell on the remote system.
Secure copy; this provides encrypted file transfer.
Secure file transfer protocol.
Nice little program for installing your personal identity key to a remote machine's authorized_keys file.
Finds and collects public host keys on a network, saving you the trouble of hunting them down manually.
Add RSA or DSA identities to the authentication agent, ssh-agent.
Remembers your passphrases over multiple SSH logins for automatic authentication.ssh-agent binds to a single login session, so logging out, opening another terminal, or rebooting means starting over. A better utility for this is keychain, which remembers your passphrases for as long you don't reboot.
OpenSSH is very flexible, and supports different types of authentication:
This uses your Linux login and password to authenticate, and your SSH keys encrypt the session. This is the simplest, as all you need are host keys. An SSH host key assures you that the machine you are logging in to is who it claims to be.
Instead of using your system login, authenticate with an SSH identity key. Identity keys authenticate individual users, unlike host keys, which authenticate servers. It's a bit more work to set up because you need to create and distribute identity keys in addition to host keys. This is a slick way to log in to multiple hosts with the same login, plus it protects your system login because the identity key has its own passphrase. Simply distribute copies of your public key to every host that you want to access, and always protect your private key—never share it.
This works like public-key authentication, except that the key pair is created without a passphrase. This is useful for automated services, like scripts and cron jobs. Because anyone who succeeds in thieving the private key can then easily gain access, you need to be very protective of the private key.
Using a passphrase-less key carries a bit more risk, because then anyone who obtains your private key can masquerade as you. One way to use passphrases with automated processes is to use ssh-agent or the keychain utility. These remember your passphrases and authenticate automatically. Their one weakness is they do not survive a reboot, so every time you reboot you have to reenter all of your passphrases. See Chapter 17 of Linux Cookbook (O'Reilly) for recipes on how to use these excellent utilities.
There are two different uses for authentication keys: host keys, which authenticate computers, and identity keys, which authenticate users. The keys themselves are the same type of key, either RSA or DSA. Each key has two parts: the private and the public. The server keeps the private key, and the client uses the public key. Transmissions are encrypted with the public key, and decrypted with the private key. This is a brilliantly simple and easy-to-use scheme—you can safely distribute your public keys as much as you want.
Server and client are defined by the direction of the transaction—the server must have the SSH daemon running and listening for connection attempts. The client is anyone logging in to this machine.