Editor's note -- In Part 3 of this multi-part series delving into the Secure Shell on Mac OS X, François Joseph de Kermadec showed you some advanced SSH techniques. Today he wraps up the final details.
Now that you know how to contact your Mac remotely, you need to find your way around it, without relying on a user interface. Obviously, this requires that you know a few basic commands like "cd" (change directory), "pwd" (print work directory), "ls" (list the contents of a directory), "cp" (copy a file) or "mv" (move or rename a file). Luckily, such commands are easy to learn.
In order to do that, you can either rely on their "man" pages or look up a few articles on the Internet. A good starting point is this MacDevCenter.com article by Chris Stone. Although it deals with earlier versions of Mac OS X, the basics are still accurate and it is very easy to understand.
If you feel a bit adventurous, you can also have a look at this slightly more advanced article by Dru Lavigne on the BSDDevCenter.
The ability to update a Mac remotely is quite amazing and will be of a great help to many system administrators who need to deploy updates on a large scale. It raises a few questions, however, that we're going to discuss so that you can update remotely with confidence.
A few months ago, Apple introduced a command called "sofwareupdate" that performs the exact same job as the Software Update preferences pane. It asks the Apple servers whether a Mac is up-to-date and installs updates if applicable.
In order to try it, simply enter "softwareupdate -l" in a Terminal window. This will launch the Software Update engine and list any updates that you may need. If everything goes well, you should see a copyright line followed by "Your software is up-to-date." Otherwise, you'll see a list of the updates.
Now, in order to install them, you'll need to gain administrative privileges. Enter "sudo softwareupdate -i -a". When prompted, enter your administrative password and press return. The "-i" flag tells your Mac that you actually wish to install the updates and the "-a" that you want to install them all. There is also an "-r" flag that installs only the "required" updates, although I wouldn't recommend using it, unless the remote computer is on dialup and needs to be urgently updated -- a critical security update, for example.
Like in the graphical version of Software Update, you'll be kept informed about the status of your query. Every update will be downloaded with a cool text progress bar showing the percent of the file downloaded. The optimizing process will be clearly labeled (so you don't think that the Terminal has frozen) and you'll be instructed to restart your computer if you installed any updates that require it.
In order to restart, type "sudo reboot" and authenticate. This will cause the remote Mac to reboot immediately, effectively closing your connection. You should, however, make sure that no applications are open and that nobody is working on the Mac. Otherwise, the computer will reboot as they work on it, potentially losing precious data and causing many panic attacks. Also, do not shut the Mac down. You wouldn't otherwise be able to access it remotely since it would require someone to manually press on the power switch.
In order to verify that the update went well, you can log in again and run
softwareupdate a second time to list the contents of the "Receipts" folder by entering
ls /Library/Receipts. One of the lines should be named after your update or it has not been successfully installed -- just keep in mind that the list can be longer than your screen and that you will probably need to scroll up or down to locate it.
As with any update, you should perform regular maintenance first and make sure that the computer is entirely idle while you are working on it. You definitely do not want someone to perform a backup or burn a DVD while you are updating the Mac -- the fact that it is possible and will probably work fine does not mean that you should do it.
You should also take into account that something might go wrong, not because of the update itself (the Mac OS X development team really does release extremely stable updates), but because a user may have installed an application you're not aware of and that interferes with the installer. That's why installing updates remotely is a delicate art and should only be performed if someone can deal with any issues locally. I don't always follow my own advice on this, but you have been warned.
Softwareupdate is without a doubt the easiest way to remotely update a Mac. Indeed, it takes care of almost everything and does not require you to enter multiple cryptic commands.
Unfortunately, all the applications you use are probably not all manageable through Software Update. Therefore, the Mac OS X engineers introduced a command-line equivalent of the Installer utility, the one you see when you double-click on a package or a metapackage (packages that include multiple packages, often used by complex applications that rely on various independent components).
What's more, this tool is capable of reading normal packages through the Terminal, which means that you don't need to request special files from developers or to alter them yourself. Note, however, that while
softwareupdate will take care of downloading the necessary packages on the server for you, you will need to place them there yourself.
The most convenient approach is to place the packages on another server that you first mount before running the command. Beware, though, of insecure protocols that may send information or passwords in the clear. Another approach is to place the packages beforehand, thanks to a USB key or a FireWire drive, but it is obviously not all that convenient. Finally, you can download them by using a command like curl.
The command-line version of Installer has the same requirements as the GUI application. It requires administrative or root privileges to run, and it cannot install an operating system on the disk it is booted from.
In order to use it, enter:
installer -volinfo -pkg path/to/package
This will print in the Terminal window a list of all volumes on which the package in question can be installed. Pick the volume you want. In our example, we are going to use "/", the startup volume.
Then, enter the following command to install the package. Note that authentication will be required.
sudo installer -pkg path/to/package -target /
The installer will then display a summary of the operations it is performing in the Terminal window. Note that there is no detailed progress indicator. Keep this in mind if you plan to run a long installation and are unsure of the status of your request. To print more information, enter "-verboseR" at the end of the command. Keep in mind that this may print a bit too much information, though, especially when the link you have established between computers is slow.
If everything goes well, result should end with "installer: The upgrade was successful." The prompt will then appear again. Do not forget to reboot the computer if necessary. Also, keep in mind that your users may be surprised to see a new application pop up in their folders. You may want to send them a mail first or initiate an iChat session to discuss the installation with them. This is especially important since launching an application while it is being installed is never a good idea -- it usually just doesn't launch, though. Also, make sure that you do not try to update an application while a user is using it.
One of the biggest tasks associated with remotely administering a computer is to perform maintenance.
Our article about Panther Maintenance should give you an idea of what should be performed and when. Some of the maintenance steps that can be performed through the command line are already covered in detail, so I won't repeat them here.
However, in order to do the rest, you can rely on another nifty remote management tool that has been recently introduced by Apple: "diskutil," the CLI equivalent of the good old "Disk Utility." As a general rule, everything that can be done through the latter can be done through the former -- and more.
Before using it directly, though, you need to get the UNIX identifiers for the various disks on your Mac, which would be the equivalent of reading the list of drives printed on the left of the Disk Utility window. In order to do so, enter "diskutil list" and enter return. This will give you a very comprehensive list of all that's inside of or connected to your Mac, drive-wise. As you can see, there are many "hidden" partitions on your drives, used to store drivers or various catalog-related files.
What we are looking for, however, are simply the lines that aren't indented and begin with "/dev/..." Indeed, they give the identifiers for every disk, which we will then use to tell
diskutil on which drive we want to act. Would you want to act on a partition, look for the identifier on the right-hand side column, conveniently labeled "identifier."
On my Mac, for example, the "Panther" volume (a partition of my internal drive) has identifier disk0s3 and my internal drive is /dev/disk0.
Without a doubt, the most commonly performed task while maintaining a Mac is repairing the permissions. In order to repair them through the command line, use "diskutil repairPermissions disk0s3" (replace disk0s3 by the identifier of your boot drive or partition). You will then see the usual messages appear on your Terminal window ( "Determining correct file permissions.", "Owner and group corrected"...). Unlike the graphical version of Disk Utility, the Terminal won't provide you with a progress bar, so you should keep in mind that the process can last a good while.
Repairing a drive usually requires you to boot from an external volume -- a CD, another partition, or even a FireWire drive. Even when you administer it remotely, the Mac is booted from its internal drive, so you still won't be able to repair this one. Nevertheless, being able to verify and repair a drive through the command line can be useful, especially if one of your non-boot partitions or peripherals is acting weird.
In order to use this function, simply type "diskutil repairDisk /dev/disk0s5". Of course, replace disk0s5 by the identifier of the non-boot partition you wish to repair. You will then see the usual messages and, hopefully "The volume appears to be OK."
Disk Utility has many tricks up its sleeve, including the ability to format drives, mount, unmount, and eject them all through the command line. In order to learn to use it -- its syntax is extremely simple -- just check the man pages. Keep in mind however that you could easily make a mistake while working remotely -- once you eject a drive, you may need to manually reconnect it or flip a switch on it to mount it again, for example. This is therefore reserved for more advanced users.
The most difficult and important part when using this command-line tool is to pick the right identifier. It should, however, be quite easy if you already make the distinction between "volumes" and "drives." For example, the two partitions on my built-in hard drive are two "volumes" on the "boot drive." When taking this into account, the identifiers make a lot of sense: disk0s1, disk0s3, and disk0s5 are obviously segments of the drive disk0.
FileVault users should keep in mind that their Home Folder is an encrypted disk image and will therefore appear as a volume of its own. Please, don't play with this volume unless you really know what you are doing, since it really is at the heart of your account.
Taking screen captures of a remote computer is at the same time a good and a bad idea. Indeed, it can allow you to easily troubleshoot an issue that a user cannot describe. On the other hand, it can be an intrusion on someone's privacy that, in some countries, can easily lead to prosecution, so make sure you don't capture anything without warning users first.
The easiest way to take a screen capture is to use the "screencapture" command-line tool. In order to capture a screen, enter the following command:
sudo screencapture -x /capture.pdf
The "x" will mute capture sounds to avoid frightening an unsuspecting user -- who should really not be unsuspecting if you follow our advice. The "/capture.pdf" specifies where the resulting PDF file should be placed. In our example, it is at the root of the hard drive. "sudo" is required when taking a capture through Terminal if you are not logged in locally as your SSH user. This is a security measure that will prevent people from spying on a user too easily -- remember that administrators are trusted users in the computing world.
You can then download the file through scp onto your Mac to view it. Do not open the file by using the "open" command. It will open the file on the remote computer, not on yours!
In order to download the file to your desktop, terminate your SSH session and simply enter:
scp user@ddnsdomainname:/capture.pdf Desktop/capture.pdf
Very often, when a user experiences an issue, you ask for detailed hardware information. A good way to make sure it is accurate is to ask the user to open the "System Profiler" utility and read its contents. Unfortunately, System Profiler is a GUI application, meaning that you cannot use it through Terminal, right?
Well, not really. Indeed, Apple thought of including a "system_profiler" command-line tool that prints the information you want to the Terminal.
Its usage is extremely simple. In order to get a report, enter "system_profiler -detaillevel", followed by a number between "-2" and "1" -- the higher the number, the longer the report.
For example, you could type
"system_profiler -detailLevel -2" to get a nice overview of what is happening on the machine you are working on. This is also a great way to make sure that updates have been installed as they should.
Many times during the completion of the steps outlined in this article, we have relied on a program that often goes along SSH, called "scp." Much like the "cp" command, it allows you to copy files. However, scp allows you to copy files between hosts and, what's more, in a secure fashion.
If you are already comfortable with cp, scp's syntax should not be too surprising. Essentially, it boils down to:
scp name-of-source name-of-destination
Name-of-source will be one or more files while name-of-destination can be either a file (to copy a file between hosts) or a directory (to place multiple files into directories). Copying multiple files into one file is theoretically possible but the file will be overwritten as the various copying operations take place -- in other words, it's not really something you want to do.
Both name-of-source and name-of-destination should follow the same structure: username@hostname:/path/to/directory. Be careful, though, since scp's syntax is quite flexible; entering a wrong character can cause the program to behave in unexpected and sometimes unwanted ways. For example "email@example.com" is a file while "firstname.lastname@example.org:" represents the default folder (home) of account "cooking" on the server tips.example.com. I have no idea if these servers or accounts exist, BTW.
A complete scp command would look like this:
scp usernameone@hostone:/path/to/file usernametwo@hosttwo:path/to/file
scp allows you to omit some elements in the command, such as the directory or the user name if you use standard or expected values. However, when getting used to scp, I would recommend that you always enter the full command. This will allow you to learn about SSH more quickly and avoid mistakes -- overwriting a file, for example. However, to download a file, you don't need to enter the full "username@hostname" address in the second part of the command -- simply have a look at the scp commands we used earlier in the article.
By using the "-r" flag, you can instruct scp to copy whole directories as well. Be careful, though. Links, aliases, and directories that loop back to themselves are not good candidates and can cause issues during or after the transfer. What you can do instead is compress the directory in Terminal and then send it as a file over the network.
The "-p" flag will allow you to retain the permissions of the files you copy. However, as a general rule, it's always a good idea to use a command such as "ls -l" to check the permissions of the resulting files on the remote machine.
The concept of SSH tunnels is a fun, powerful, and interesting one. Let's imagine what happens when you use a VNC client to connect to a remote computer through a graphical interface. When you establish a connection, a big glass pipe is run between your Mac and the remote computer you are controlling.
This glass pipe is transparent; anybody can see what is going on inside of it and read the information it contains. It is also fragile. Anybody with readily available tools can smash the glass wall and add things to the pipe, right in the middle of the stream.
As you can see, this is far from a secure connection. However, since the material the pipe is made of is decided by the protocol you are using, your only option to secure it is to put this big pipe into another, more robust one. I like to think of it as stainless steel but pick your metal of choice. That way, the outside pipe will protect the inside, fragile one from prying eyes and intrusion tools, while being designed for easy plumbing. Best of all, since both pipes are well-designed, you do not need to modify the inside one. It simply slides right into the metal shell.
This is exactly what SSH can do. If you have to use insecure protocols (glass pipes), you can instruct them to pass through a secure SSH connection that will be wrapped around them (the metal pipe), effectively securing them. The good news is that SSH is, like our metal pipe, entirely transparent to the insecure application and is therefore extremely unlikely to disrupt anything.
SSH tunneling is out of the scope of our discussion, directly at least. There are, however, some great tunneling-related articles on the O'Reilly Network that provide you with step-by-step tutorials. Secure Mail Reading on Mac OS X by Jason McIntosh is an excellent starting point.
SSH is a flexible and powerful protocol. Thanks to the Mac OS X engineers, it is also incredibly easy to use on a Mac. By learning a bit about it and practicing in your Terminal, you can bring your computing and networking experience to the next level.
Ben Lindstrom from the OpenSSH group was kind enough to provide me with information regarding some detailed SSH configuration settings. May he find here the expression of my gratitude. Needless to say, any errors or inaccuracies in the preceding pages remain entirely my responsibility.
FJ de Kermadec is an author, stylist and entrepreneur in Paris, France.
Return to MacDevCenter.com.
Copyright © 2009 O'Reilly Media, Inc.