Editor's note -- In Part 1 of this multiple-article series delving into the Secure Shell on Mac OS X, François Joseph de Kermadec explained why you should explore the SSH server built into your Mac. Now, in Part 2, he shows you how to get started working with these tools.
While setting up our SSH server and client, we'll assume that you have physical access to both machines and that these are conveniently located next to each other, so that you can read information off one screen and type it onto the other computer's keyboard. While it's possible to follow the steps we outline in less practical environments, you may need to keep a pad and a pencil handy. Also, make sure that nobody is "shoulder surfing" (reading information over your shoulder) while you work on the computers. We are, in the following paragraphs, going to deal with sensitive passwords that should be kept secret at the risk of ruining all your security and privacy efforts.
Also, before we start, we are going to perform two operations on the "server machine" -- in other words, the machine that you wish to administer remotely. While they may not make sense right now, I promise they will in a few seconds and I will point out their significance as we encounter them.
The big problem when setting up a Desktop Mac as a server is that it's easy to forget that, while Desktop Macs should go to sleep when they are not used, servers should not. Indeed, in many cases, a server that is asleep cannot be awoken remotely and the link to it simply dies, without any chance of it being reactivated.
Sure, Mac OS X features a great "wake for administrator access" option, available through the Energy Saver Preferences pane. However, such options do not always work on WANs and should be avoided whenever uptime is a priority.
Therefore, before thinking of setting up your server, you need to use the Energy Saver Preferences pane so that:
You should also invest in an interruptible power supply for your Mac and modem or, at least, a surge protector so that they don't get damaged when you are not here. If you use a phone modem, use a phone surge protector, too, since phone cables happily conduct surges right into your modem card (or worse, motherboard) and have already destroyed more than one computer.
If you need to restart your Mac remotely, it is a good idea to use the "Security" and "Accounts" Preferences pane to disable automatic login. Indeed, this could cause the Mac to log into your account while you are not here simply because you rebooted it remotely, giving access to your files to anyone walking nearby -- yikes! Logging out of a GUI session remotely involves killing processes or hacking the login window preferences file before restarting again. It can be done -- I have done it -- but it's definitely not a risk you want to take.
Finally, put signs or instruct your users to only log out, and never to shut the computer down or put it to sleep unless there is an emergency. Hiding the "shut down" button on the login window can help a great deal, too. "Simple Finder" accounts do not feature a "Shut down" menu, making managing the Mac remotely a lot easier, especially if your users are beginners and may not appreciate the importance of not shutting the computer down.
While the steps we are going to see today should be sufficient for most home users and small businesses, users handling sensitive data may want to seek professional help or training. If you have a system administrator, do speak with him about SSH and your wish to use it. Some restrictions or special policies may apply to your network.
SSH is a fascinating, complex, and powerful protocol. We're going to see together how to use it in your everyday workflow and make it more secure than it is in its default configuration. You may want to have a look at more detailed resources to learn all that SSH can do for you. I highly recommend SSH, The Secure Shell: The Definitive Guide by Daniel J. Barrett and Richard Silverman.
We have already seen that, as secure as SSH may be, it does not protect you against compromised hosts. Therefore, you should pay attention to the security of both computers, the server (the machine you are administrating remotely) and the client (your administrative machine).
This is especially important for two reasons. Since you're creating a link between the two computers, a skilled attacker could take advantage of it to compromise both computers easily, if he has already compromised one. Also, since you will be away from the remote computer, preventing and detecting security issues is likely to be a lot more difficult than if your were there. Make sure that you at least follow the advice described in our Security Primer for Mac OS X article -- both machines and all the users who use or monitor the server should have a way to contact you easily in the event of an issue.
Now that we have discussed theory, it's time to roll up our sleeves and meet SSH by turning it on the server machine. In order to do so, follow these steps.
If you use a third-party firewall, make sure that it allows connections to port 22, the default SSH port. If you rely on the Panther built-in firewall, you do not need to worry. Mac OS X is actually smart enough to stop blocking that port as soon as you turn remote logging on.
Keep in mind that, although SSH is a secure protocol and the SSH server supports some strong authentication methods, running a server (of any kind) on a computer (any platform) weakens its ability to resist attacks. You should make sure that your network is properly firewalled in all instances, and that you apply any security update that has been released and will be released by Apple. Indeed, if a serious security issue is discovered with the OpenSSH server, only an appropriate update can protect you against attacks.
If you don't have a firewall, and if your Mac is directly connected to the Internet, I would strongly advise you to purchase a hardware firewall. This will provide you with a very valuable layer of security and will protect your computer from many attack attempts.
If you already have a firewall, now is a good time to make sure that it is properly set up and that its firmware is up-to-date. Indeed, the mini-operating systems contained inside of firewalls do need to be updated from time to time; failure to do so could allow a remote attacker to exploit a known issue in the software and take control of your router -- a scary thought.
As an additional security, you can also test your firewall by using the online tests provided by various security companies on the Internet. You may find the tests from Symantec and Sygate complementary and useful. Of course, these tests cannot replace a true security audit.
|
You now have a fully functional SSH server running on this Mac. In order to test it, plug your administrative machine into the same subnet and open a Terminal window. Then, enter the magical "ssh username@ipaddress" command that you wrote down. This command simply starts the ssh client built into Mac OS X and causes it to establish a connection to the SSH server you just set up, requesting to be logged as the specified user.
I wish you could login directly but, unfortunately, that's not what happens. You see, in order to make SSH connections secure, the client and the server try to prove their identities to each other before dialoging. In order to do that, they engage in a cryptographic exchange based on keys that are preinstalled on both machines.
This is a way to prevent someone from impersonating your server and capturing your sensitive data -- a process known as a "man-in-the-middle" attack that involves passing back and forth data between an unsuspecting client and server who both think they are talking directly to each other. Since this is the first time that your client and your server meet, they have no way to make sure that they are who they claim to be. Therefore, SSH will call you for help and display the fingerprint of the cryptographic key used by the computer that pretends to be your server to identify itself -- also called the "host key."
Go to your server and enter the following command and press return:
ssh-keygen -l -f /private/etc/ssh_host_rsa_key.pub
It will get the fingerprint of the server's RSA key, which will be used as a unique identifier by SSH.
Simply compare the two strings. If they match, you can be sure that your computer is indeed talking to the server and not to some evildoer. Type "yes" to confirm the connection and to reassure SSH. SSH will then resume the normal login procedure.
You normally should not see this message again since SSH has written down the key it asked you to check as a "trusted" key for future reference. If you see it again this may mean that someone is impersonating your server. You should immediately disconnect your computer, pick up your phone, and call your network administrator.
SSH will then ask you for the password of the account you are logging into. Type it, press return, and you will be logged in as the user you specified (user "username" in our example). Any action you perform in this Terminal window will act on the other computer. For example, typing a command that causes the CD tray to open will open the CD tray of this machine, not yours. Be careful with that since it is easy to make mistakes and frighten unsuspecting users thousands of miles away from you who will see their optical drive wake up for no apparent reason.
To give you feedback of what you are doing, try typing a command like:
say I sure love being inside this fancy computer
That will cause Victoria's sweet voice to be heard through the remote computer's speakers.
Finally, in order to close the SSH session and go back to your local command line interface, enter exit and press return.
We now have a Mac listening on the network for SSH requests, ready to grant privileges to anyone guessing the password of any account it contains. This is the default behavior of most SSH servers and, if you have picked a good password, the chances of someone guessing it are not too high. However, they do exist and should not be neglected.
In order to compensate for these issues, we are going to disable password authentication and only allow public key-based authentication, meaning that the SSH server running on the Mac will only grant access to someone possessing a specific private key, even if this person guesses an account password. Since private keys never leave your computer, stealing them requires breaking into your machine.
Furthermore, since the private keys you store on your Mac can be encrypted by the use of a password, successfully logging into the remote server requires two things: something that you have (the key) and something that you know (the password for the key), making this authentication method very solid.
Note that this is theoretical. If a vulnerability is discovered in the OpenSSH server, a remote attacker could try to exploit it to gain access to the computer without possessing the key or knowing the password for the account. This is why it is especially important to stay on top of security announcements while running a server on a computer.
Of course, there are some features built into OpenSSH that lessen the chance of a vulnerability being exploited in a useful way -- one of them being called "privilege separation." You should, however, not rely on them to counter each and every threat that could arise.
Obviously, before we can think of using keys to authenticate ourselves, we need to have some. The good news is that -- unlike when you were setting up mail certificates -- you do not need to ask a certification authority for your keys. Indeed, we do not need to prove our identity to the world and can therefore create our own keys from the comfort of our Terminal windows.
In order to generate the keys, we are going to use a built-in command-line tool called ssh-keygen from the client -- i.e., your administrative computer.
As usual, open a Terminal window and type the following command, followed by return:
ssh-keygen -b 1024 -t dsa
It will create a dsa key (DSA being one of the two algorithms used by SSH2, the other being RSA) with a length of 1024. If you decided you need to use SSH1 protocol do not reuse your SSH2 RSA key. They are used differently, and the results could expose information that can be used to compromise your private key. Thus, it is always better to generate a separate SSH1 RSA key (ssh-keygen -b 1024 -t rsa1).
Ssh-keygen will ask you for the location where it should store the generated keys. Simply press Enter to install them into the default location, where the various SSH components will expect to find them.
When prompted for a pass phrase, enter a "good password" -- as defined in our Mac OS X security primer article -- that will be around 15 characters long. Remember that this password prevents a malicious program on your Mac or an attacker from using a stolen key. It is therefore extremely important and sensitive. Of course, make sure that you do remember it.
Ssh-keygen will then exit gracefully, printing the key's fingerprint on the screen.
Ssh-keygen saved the two keys it generated on your computer. However, in order for the server to make use of them, you must upload your public key onto it, in a location where it will be able to automatically locate it and use it.
In order to do so, we are going to use scp, a command that rides along SSH. Despite having an easy-looking syntax this command is capable of handling secure file transfers transparently. Indeed, by just entering the scp line, you will open a secure connection, transfer the files over it, and close it, all in one go.
To copy the files, type the following command in a Terminal window:
scp ~/.ssh/id_dsa.pub username@serverip:~/.ssh/authorized_keys
As you can see, it copies (scp) the public dsa key we just created (~/.ssh/id_dsa.pub) into the .ssh folder of the remote user's home and renames it authorized_keys.
As a side note, you may sometimes hear of a file called authorized_keys2 -- while it should work with the current version of OpenSSH, the generic name is now preferred. This file can be used by both SSH1 and SSH2.
In case you were wondering why I advised you to manually create a folder called .ssh on your server's earlier. This is simply because this scp command needs it!
Authentication will take place like it did with our previous SSH login trial. However, scp exits all by itself and you do not need to type a special "exit" command.
Now that you have uploaded your public key onto the server, it's time to test whether SSH sees it. In order to do so, log in from your administrative machine. Instead of the password of the remote account, you should be asked for the password that you used to encrypt the key.
However, you will soon notice that failure to provide SSH with this password won't terminate the connection, as we would like. Instead, it will fall back to the less secure password prompt.
Here is a troubleshooting tip. If the SSH server does not work as expected and doesn't prompt you for the password, this may be because your home, .ssh folder, and authorized_keys file are world- or group-writable. This is a security measure that prevents the server from relying on keys that could be easily compromised. If you still experience issues, make sure that your client (the Mac you are using to perform the remote administration) is correctly set up, too, and that its permissions scheme is strict enough.
Therefore, our next step will be to edit the SSH server configuration files in order to disable all these weaker authentication options that we do not like.
Next week I'll get into editing configuration files and show you some great tips for maintaining secure control of your SSH communications.
FJ de Kermadec is an author, stylist and entrepreneur in Paris, France.
Return to MacDevCenter.com.
Copyright © 2009 O'Reilly Media, Inc.