Hack 71 Remotely Log In to Another Machine via SSH

Interact with a remote machine from the command line via SSH, the Secure Shell.

Once you've acquired a taste of the Unix command line underlying Mac OS X, it's hard to stick only to the machine at hand. You want to log in to that old-but-upgraded PowerMac 7500 with G3 card in the closet to see how your web server's faring. Your friend invites you to drop in on his X Server across the country to check out his latest Perl hacks. The FTP server in your office doesn't appear to be allowing incoming FTP requests, despite being pingable (read: online and alive).

Forget remote screen-sharing applications; who needs a candy-coated graphical user interface to accomplish the remote administration tasks at hand? From the command line you can do most anything you can do locally ? except play that addictive new fully immersive GUI game you left in your office machine's CD drive.

71.1 Introducing SSH

SSH, the Secure Shell, is a command-line utility for interacting with a computer over the network as if it were local, attached directly to your keyboard. SSH differs from other remote access options (e.g., Telnet) in its focus on security; all communication is encrypted, end to end. This means that anyone tapped into your network (called a man-in-the-middle attack) won't see much more than gibberish floating by. And it does this in a fast, safe, and intuitive way, making for some interesting and powerful hacks.

For everything you ever wanted to know about SSH, take a gander at O'Reilly's SSH, The Secure Shell: The Definitive Guide (http://www.oreilly.com/catalog/sshtdg).

71.2 Allowing Remote Login

Mac OS X, being a Unix-based operating system, comes with SSH remote-login capability baked right in. Before you can log into your Mac remotely, however, you do need to turn on SSH. Open the System Preferences Sharing pane and select the Services panel. On the left is a list of services supported by OS X; along with Personal Web Sharing [Hack #88] and Printer Sharing is Remote Login. If it's off, start it up either by selecting it and clicking the Start button on the right or by clicking the associated checkbox. After a few moments of Remote Login starting up . . . , your Services panel should look something like Figure 6-14.

Figure 6-14. Allowing remote login

Of course, this does little good if the computer isn't accessible from wherever you need to be while accessing it. This usually isn't a problem when you're on the same local network in your house or office. If you intend to log in remotely from somewhere else on the Internet, check with your system administrator or Internet service provider about addressing [Hack #78] and reaching your machine.

71.3 Getting from Here to There

To log in to a remote machine, whether it be another Mac, Linux box, or anything else running SSH, open a Terminal [Hack #48] window and type:

% ssh -l username
 remote_machine

Substitute your login name on the remote machine for username and the name or IP address of the remote server for remote_machine. If, for example, I were logging into a machine called foo.example.com using the login raelity, my session would start out a little like this:

% ssh -l raelity foo.example.com
Last login: Thu Dec 12 10:34:03 2002 from 123.somewhere.isp.net
Linux 2.4.18.

raelity@foo:~$

If your remote login name is the same as your local one, you can forego the -l username bit, typing only:

% ssh remote_machine

That's all there is to it. You should now be on the command-line of a remote machine. Depending on the operating system running over there, it will look to some degree or another like your local Terminal command line.

71.4 Copying Files over SSH

It's just about as easy to copy files to and from an SSH-enabled machine as it is to copy them from one local directory to another on the command line, thanks to an SSH-based version of the cp [Hack #48] command, scp. It goes like this:

% scp login
@remote_machine
:/path
/to
/file
 .
% scp filename
 login
@remote_machine
:/destination
/path

The first line copies a file from remote_machine, using the username login to your local current directory (.). The second line does the exact opposite. For example, to copy a file called notes.txt in the /tmp directory on the remote machine, foo.example.com, as user sam to your local Documents directory, like so:

% scp sam
@foo.example.com
:/tmp
/notes.txt 
~/Documents
sam@foo.example.com's password: 
notes.txt 100% |*****************************| 22 00:00 

scp works just about the same as cp, allowing you to copy multiple files (this works when copying files from here to there, not there to here), rename them during copy, and so on:

% scp image*.jpg sam@foo.example.com
:~/images
% scp sam@foo.example.com
:/tmp/notes.txt
 ./lecture_notes.txt

71.5 Port Forwarding

SSH isn't only for securing interactive remote sessions; you can piggyback just about any network traffic on it, adding a wrapper of ironclad security to anything you may be doing over the network. For an example of so-called port forwarding over SSH, see [Hack #70].

71.6 Remote Reboot

Your remote machine's stuck for some unfathomable reason, the screen frozen and mouse immobile (not that you can see it). Yet you still seem able to log in remotely. To remotely reboot that machine, SSH in and type:

% sudo reboot

Wait a short while and, assuming it comes up cleanly, all should be well.

71.7 Remote Screenshot

The combination of OS X's command-line screencapture utility [Hack #41] and SSH means being able to take a snapshot of a remote machine's desktop.

Simply log in remotely, type screencapture filename.pdf, and scp the file back over to your local machine.

This is a nifty way, by the by, to capture the Mac OS X Login screen.

71.8 SSH Without Passwords

When you're working with more than a few machines, having to type ssh my.server.com (followed by a password) is not only tedious, but it breaks one's concentration. Suddenly having to shift from "Where's the problem?" to getting there and back to "What's all this, then?" has led more than one admin to premature senility. It promotes the digital equivalent of "Why did I come into this room, anyway?"

At any rate, more effort spent logging into a machine means less effort getting your work done. Recent versions of SSH offer a secure alternative to entering a password endlessly: public key exchange.

To use public keys with an SSH server, you'll first need to generate a public/private key pair:

% ssh-keygen -t rsa

You can also use -t dsa for DSA keys, or -t rsa1 if the machine at the other end is using SSH Protocol v1 (Protocol v2, the default, is a better choice).

After you enter the preceding command, you should see this:

Generating public/private rsa key pair.
Enter file in which to save the key (/Users/rael/.ssh/id_rsa):

Just press Return to accept the default. ssh-keygen will then ask you for a pass-phrase; just press Return twice (but read the note on security later in this hack).

The results should look something like this:

Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/rob/.ssh/id_rsa.
Your public key has been saved in /home/rob/.ssh/id_rsa.pub.
The key fingerprint is:
a6:5c:c3:eb:18:94:0b:06:a1:a6:29:58:fa:80:0a:bc rob@localhost

This created two files, ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub. Now you need to get those keys over to the destination machine; future SSH sessions will notice that you've got matching keys on both sides and not bother you for a password. Let's use SSH itself to copy the keys. The first command creates a remote .ssh directory, while the second copies the keys there:

% ssh server "mkdir .ssh; chmod 0700 .ssh"
% scp .ssh/id_rsa.pub server
:.ssh/authorized_keys2

Of course, you should substitute the remote machine's name or IP address for server. It should ask for your password both times. Now, simply SSH in (e.g., ssh server) and you should be logged in automatically, without a password. And yes, your shiny new public key will work for scp, too.

If that didn't work for you, check your file permissions on both your local and remote ~/.ssh directories and the files within. Your private key (id_rsa) should be 0600 (and be present only on your local machine), and everything else should be 0655 or better.

Some consider the use of public keys to be a potential security risk. After all, one only has to steal a copy of your private key to obtain access to your servers. While this is true, the same is certainly true of passwords. Ask yourself, how many times a day do you enter a password to gain shell access to a machine (or scp a file)? How frequently is it the same password on many (or all) of those machines? Have you ever used that password in a way that might be questionable (on a web site, a personal machine that isn't quite up-to-date, or possibly with an SSH client on a machine that you don't directly control)? If any of these possibilities sounds familiar, then consider that an SSH key in the same setting would make it virtually impossible for an attacker to gain unauthorized access later (providing, of course, that you keep your private key safe).

?Rob Flickenger