AddThis Social Bookmark Button

Print

Inside SSH, Part 1

by FJ de Kermadec
07/09/2004

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.

About SSH and Why We're Picking It

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.

OpenSSH

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.

Command Line? Are You Mad?

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.

Pages: 1, 2

Next Pagearrow