AddThis Social Bookmark Button

Listen Print Discuss
Mac OS X > Excerpts >

Inside SSH, Part 1
Pages: 1, 2

Prerequisite: A Word About Cryptography and Keys

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.

When SSH is Not SSH

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.

Next Time

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