Whether you're a system administrator trying to help users scattered around office locations or an experienced Mac user struggling with multiple accounts, you surely have wished you could easily access all of the Macs you are working on remotely. And, since you're aware of the various threats that any user encounters on the Internet today, you probably wish to access them securely, without compromising the security of your data or of your passwords. Moreover, if, like an increasing number of Mac users, you've switched to an all-laptop solution, then you need remote administration tools that are flexible enough to work on high-bandwidth networks as well as old-fashioned dial-up ones that can still be found even in otherwise modern areas.
Well, as the song says: "I have news for you!" Thanks to Apple's dedication to intelligently using and promoting open source software as well as their focus on security, all of the tools you need to accomplish this technological tour de force are included right in your default installation, or can be downloaded from the Internet in a matter of minutes.
This is the first part of a three-part series where I'll show you how to turn on, secure, and leverage the power of your Mac's built-in SSH server. Along the path, we're going to have a look at asymmetric cryptography, digital signatures, and SSH tunneling -- some very interesting concepts that, with a bit of practice, will allow you to take your computing experience to a whole new level.
SSH stands for Secure SHell. However, it is not a shell in the traditional sense. It's, in fact, a protocol that allows you to remotely log into a machine, over a secure, encrypted link.
By using SSH, you can control a computer much in the same way as if you were sitting in front of it, banging on its own keyboard. In fact, most headless -- i.e., without monitor -- servers in big network rooms are administered remotely via tools like SSH. However, what makes SSH different than the other remote login programs that have been distributed with UNIX-like operating systems for quite some time now is that it also provides three essential elements: authentication, encryption, and integrity.
Authentication means that SSH won't grant rights to a user requesting a connection without asking for a proof of identity and making sure that the user is in fact who he or she claims to be. While this may sound silly, your whole computing experience revolves around strong authentication: without it, your identity could be stolen and actions performed with your privileges and in your name. Yikes!
Many remote login programs do handle authentication in a somewhat sloppy way and can be easily tricked into granting rights to someone who should not have them -- a process known as "spoofing," made all the easier by the fact that many of the protocols upon which networks rely weren't designed with authentication in mind. What's more, SSH is able to use many forms of authentication, from the simplest to the most elaborate -- think passwords, PAM, S/Key (one-time passwords), SecureID, and others. Today, we are going to talk specifically about Public Key Authentication, since it is at the same time extremely powerful and convenient.
Encryption means that the data that travels on the network between the two computers that communicate cannot be understood by malicious users. They can still intercept it but, as far as they're concerned, it's a useless pile of nonsense. Other remote logging programs have a tendency not to encrypt anything, meaning that your passwords and confidential files can be read and stolen while they travel over the network. Encryption is handled transparently by SSH, which means that the commands passing through the tunnel do not need to know anything about it. It also happens end-to-end; unless one of the two computers has been broken into, there is no way for an attacker to read the information in its clear-text form.
Integrity means that although the data can be altered during the transfer (this is a side effect of TCP/IP, the protocols on which the Internet is built), SSH would immediately notice this and would discard the altered data without using it. Should you think that integrity is not that big a deal, think again. It's quite easy for someone to pump malicious commands into the pipe that a remote login tool creates between two computers. "Ooops! Who sent to the server an order to transfer $10,000 to a bank account in California? I wanted to send $10 to a company in Spain."
In fact, SSH is said "not to trust the network and to put minimal trust in the server or the domain name servers used by the network." In other words, SSH will consider the environment it is working in as a dangerous one and will try to rely on it as little as is possible.
Even better, SSH is able to act as a helper application for other programs that would otherwise not have been able to communicate securely over the Internet. For example, it can be used to create a "tunnel," inside of which you can copy a file (this will be done by using the
scp program directly) or through which you can use a graphical user interface administration (GUI) tool such as VNC.
This is why all the operations that we are going to discuss in this series rely on SSH to a certain extent. In fact, we will spend quite some time setting up and fine tuning SSH. Once your SSH connection is up to speed, you will see how easily the various pieces of the puzzle will come together.
Nowadays, many excellent graphical user interface tools are available, making administering a computer remotely quite easy, even if you do not want to learn arcane UNIX commands. Such products include the amazing Apple Remote Desktop, which I highly recommend to network administrators and IT support staff -- or even some cross-platform, free solutions that, although perhaps less convenient for administrative use, can be of invaluable help.
Unfortunately, such ease of use comes at a price: transferring a whole interface across a network, including mouse movements, clicks, and key strokes is extremely bandwidth-consuming, making such GUI tools more suited for local administration than remote operations. Also, some of them may lack encryption features, just like their Terminal-powered counterparts.
This is why I am going to show you how to remotely connect to, and control, a computer through the Terminal. As you are going to see, this is all quite easy, does not involve black magic, and is extremely rewarding, since it allows you to work efficiently even in "hostile" conditions.
As an example, while I am typing this article, I am installing Mac OS X v.10.3.4 on my iMac located in Paris, from the comfort of a patio chair by a pool in New Orleans. This connection is far from optimal. It goes through a wireless link, a relatively slow cable network, all the way around the ocean, through my French DSL provider, and through my router. Nevertheless, I can type in my remote
tty -- geek-speak for Terminal, a reminiscence from the good old UNIX days I didn't experience -- with the same ease that I can in my local one. Although we're going to discuss such matters later, let me say that the complete upgrade process (installation and reboot) went flawlessly, even from that great a distance.
If you don't want to learn UNIX commands, keep in mind that having a command-powered "backdoor" (so to speak) into a computer that you usually administer remotely gives you additional options, should the graphical administration tool fail for some reason. For example, you can log in, delete a corrupted preferences file, and resume your work in a matter of seconds. Of course, this is not an entirely foolproof process -- since you will need to know on which files your tool of choice relies to perform its magic -- but it can be extremely effective in some situations.
I also want to note that you're unlikely to damage (i.e., delete or alter) files on your hard drive by performing the commands I am going to show you in this series. Simply make sure that you understand what you are doing, read the
man pages if necessary, and make sure that you enter the commands correctly. However, this article has some security implications, and you should not forget to back up data on both your computer and the one you want to administer, especially if you are dealing with SSH and/or the Terminal for the first time.
Since we're going to talk a fair bit about asymmetric cryptography and keys in this article, I thought it would be more convenient to gather all what you need to know about them before we begin. That way, I won't have to bother you with these (fascinating) technical details later on.
Asymmetric cryptography relies on the use of two encrypting and decrypting devices called keys. Roughly speaking, you can think of keys as of complex, machine-generated passwords. In a more technical way, we could say that they are random streams of binary data. One of these keys is called a public key and is distributed freely by its owner, to anyone who wishes to communicate securely with him. To send an encrypted message to the owner of the key pair, correspondents just need a special encrypting program to which they will give the cleartext message and the key.
Here's what makes the system interesting: the resulting encrypted message (or cyphertext) can only be decrypted by the private key, the one that the owner does not distribute and protects at all costs. This means that even the other correspondents who own the public key won't be able to decrypt the message.
As you can see, this solves the major drawback of symmetric encryption. Since, with this system, the same key can encrypt and decrypt the messages, it must be exchanged securely by the two correspondents before they can begin to talk to each other, which is almost infeasible over the Internet. Also, there can only be two correspondents for a key, since giving the key to a third person would put the communications of the first two at risk. Just imagine the number of keys we would need in our everyday workflow!
These keys can also be used to prove the identity of someone. In fact, a digital signature is considered in many countries to be as valid as a paper-and-pencil one, a whole new concept that is not without legal issues. It works in quite a simple way: a mathematical operation is performed on a document and the result is encrypted with the private key.
The encrypted result is then sent along with the document and the sender's public key. In order to check the signature, the recipient needs to perform the same mathematical operation and compare it with the result sent along with the document, which has been previously decrypted with the public key. The key pair is signed by a certification authority (CA) that guarantees (to varying extents) that it belongs to someone.
Servers can also prove their identity to each other through a cryptographic exchange: instead of encrypting a document, the owner of the public key sends an encrypted random string and waits for the other side to send it back decrypted, meaning that it owns the private key. There is more to it, actually, but you get the idea. Notice that, with such a system, the actual private key never leaves the computer on which it is stored. This makes key-based authentication extremely difficult to subvert, since the attacker cannot even try to steal a key in the same manner as a password that travels on a network -- even if it is in an encrypted form.
Since keys are extremely long, comparing them bit by bit would definitely not be practical for the average user. Therefore, cryptography has come up with a value known as the key fingerprint that is derived from the key thanks to some advanced math. Much like there are theoretically no two human beings with the exact same fingerprints, there should not be two keys with the same fingerprint. As you can imagine, this is a theory, since keys are extremely long and fingerprints extremely short.
Nevertheless, the risk is considered acceptable. In situations where you would need to check two instances of a key file to compare that they are identical, you could turn to their fingerprints instead of checking the files manually. Should you use the checksums provided by many download sites in order to check the integrity of the files you get, you should already be familiar with the system. In fact, SSH and SHA1 checksums are not entirely strangers to each other.
If you want to learn more about the world of keys, you can have a look at our "Encrypted Mail on Mac OS X" article that provides an introduction to the system, as well as links that you may find of interest.
In this article, we use the acronym SSH to designate both the SSH protocol and the SSH client or server running on Mac OS X computers. However, for the sake of clarity, we should pause for a moment and make sure that we do know the principal meanings SSH can have.
There are in fact two versions of the SSH protocol, called SSH1 and SSH2. Indeed, weaknesses found in the SSH1 integrity check system have, among others, prompted the development of SSH2, which is even more secure. However, for various technical reasons, deployment of SSH2 has been slower than expected and SSH1 is still widely in use. Indeed, while it is much more flexible than SSH1, SSH2 can be at times more complex -- its structure is a lot more modular, and it uses different algorithms.
There are many SSH clients and servers; some commercial, some not. In Mac OS X, Apple chose to use OpenSSH, a well-known, time-tested, open source version of SSH that is capable of handling both SSH1 and SSH2, all in the same package. If you're already used to another SSH setup, you may notice some subtle differences in the configuration options.
This is normal since, although various distributions are similar in many points, they all have their particularities. Installations that do not use OpenSSH often rely on two programs, SSH2 and SSH1, capable of calling each other to handle the appropriate connection requests -- which is not without administration headaches, as it forces you to set up two SSH servers instead of one for optimal security.
The OpenSSH suite includes in fact many programs, most of which we are going to use at one point or another:
scp, which allows you to remotely and securely copy files;
sftp, which replaces the standard, insecure
ftp command; and utilities that are used at various stages of the key creation and management process, such as
ssh-keygen, which generates cryptographic keys.
The software is developed outside the U.S., using code from roughly 10 countries, and is freely useable and reuseable by everyone, under a BSD license.
You can find a detailed introduction to OpenSSH and its history on this page.
Now that we have all of our prerequisites out of the way, we can roll up our sleeves and get to work. Join me next Tuesday for part two, where we fire up the Terminal and get secure. See you then!
FJ de Kermadec is an author, stylist and entrepreneur in Paris, France.
Return to the Mac DevCenter
Copyright © 2009 O'Reilly Media, Inc.