oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

Inside SSH, Part 3

by FJ de Kermadec

Editor's note--In Part 2 of this multipart series delving into the Secure Shell on Mac OS X, François Joseph de Kermadec showed you how to securely fire up the Secure Shell and start communicating. Now, in Part 3, he digs deeper, showing you more advanced techniques.

Editing the Files

Editing configuration files is actually extremely simple once you know how to work with them. These files are simply text documents containing a list of settings and their associated values--one setting and its corresponding value are usually on the same line.

To change the value, simply erase the text and replace it with the new one. In some cases, the line will be preceded by a hash sign (#), meaning that it won't be taken into account by SSH. Simply remove the sign after you've changed the value so that the change you've made can be read and taken into account. Such a line is a default, meaning that it is normally the value your SSH server adopts. However, uncommenting it will make things clearer for you and may help you avoid an unexpected configuration glitch.

For example, if I wanted to change the imaginary option "SayHelloAndSmile," I would change:

# SomeStrangeSetting yes
# SayHelloAndSmile no
# SomeStrangeSetting yes


# SomeStrangeSetting yes
  SayHelloAndSmile yes
# SomeStrangeSetting yes

In order to edit the files, I would recommend that you use pico, a simple text editor that lives right in your Terminal. Once you've opened a file in pico, use your arrow keys exclusively to navigate. At the bottom of the window, you will see reminders of useful shortcuts. Simply keep in mind that "^" means "Control," and you're good to go!

To edit the file, you can either SSH into the server or sit in front of it and use its keyboard.

The Server Configuration File

In order to open the server configuration file in pico, type the following command and press Return:
sudo pico /private/etc/sshd_config

You will be asked for your administrator password. Make sure that you provide the one for the account you are logged in to.

PermitRootLogin no

Turning this option off will prevent anyone from logging as root through SSH. Because no administrative task should be performed in the root account--unless you are a really advanced Unix user and know the consequences this may have--this will greatly increase the security of your setup without preventing you from doing your work. Because the root account is all-powerful in traditional Unix systems, it is the one that most often is targeted by remote attackers--another good reason to prevent access to it.

PasswordAuthentication no 

Password authentication is the weak authentication scheme we are trying to avoid. Therefore, turning it off is our main goal.

PermitEmptyPasswords no

Nothing is more dangerous than an account with an empty password. As a security-conscious administrator, you already should have made sure that no user account is set up that way. However, for additional security, make sure that you use this option: When it is turned on, SSH will deny access to any account that does not have a set password.

PubKeyAuthentication yes 

Public key is the strong authentication scheme we are working on. Therefore, it is essential that you enable it--or you could lock yourself out of the remote machine, which is never a comfortable situation.

RSAAuthentication no 
RhostsAuthentication no
ChallengeResponseAuthentication no 
PAMAuthenticationViaKbdInt no

These authentication schemes are weak or do not apply to our setup. Therefore, it is best to turn them off. Leaving them on would defeat our efforts to secure the SSH server.

StrictModes yes

When this option is enabled, SSH will make sure that the user's files and directories that are involved in the SSH logging process are adequately protected by the permissions scheme on the server. If this were not the case, SSH would simply deny the connection. Of course, file permissions are far from the ultimate security system, but they still provide some level of security that we should not knowingly neglect.

LoginGraceTime 30

When this option is enabled, SSH will give you 30 seconds to authenticate, after which the connection will be closed. That way, an attacker trying passwords or hesitating will have to request multiple connections, which slows him down. Also, it will prevent the server from listening to connections that are not going to be used and were established by mistake. Ideally, this value should be just long enough to allow you to type your password quickly--but if it's too short, you could lock yourself out.

KeyRegenerationInterval 3600
ServerKeyBits 768

These two settings will make sure that the server key, which is used in the encryption and securing process, is long enough and will be changed frequently. Indeed, the more data is encrypted with a key, the easier it is to guess it and to crack the encryption. By creating a new key frequently, you can prevent such attempts.

Protocol 2

This option will restrict the OpenSSH server that runs on your Mac so that it uses only the SSH2 protocol, which features a better integrity check mechanism and is considered more secure. While recent versions of the OpenSSH client normally default to SSH2, it will prevent any remaining SSH1 authentication mechanism to cause your remote Mac to rely on this older protocol. It will also make things more difficult for potential malicious users by limiting their options and the number of vulnerabilities they can try to exploit.

AllowUsers username

You'll actually have to add this line. Of course, replace username with the name of the account(s) you want to be able to SSH into. The goal of this line is to prevent SSH connections to any account that has not been explicitly authorized. It adds a layer of security that is always welcome and prevents forgotten keys from firing back when you least expect it.

If you want to refine this setting, you can enter a list of usernames or username patterns, separated by spaces. For example, you can use the traditional Unix wildcards ? and *. Just keep in mind that user IDs do not work with this keyword.

Finally, you can write the username in a user@host form, allowing log in only to a user from a specific host. However, be very careful with this option; it does not considerably improve security and, knowing how easily host names can change on networks, you could lock yourself out of your own server easily.

SSH features a DenyUsers command that you may use instead--don't try to use both, though, since they can conflict. In this case, AllowUsers is more powerful and should be what you are looking for.

To save your work, type Control-O followed by Return. Then, to exit pico, type Control-X, which should cause the prompt to reappear.

Securing the Client

Securing the host is the most important part of our process. However, by setting up a few options in the client configuration file as well, you can reduce the length of the SSH authentication procedure and prevent SSH from falling back to insecure methods without your knowledge or approval.

This time, you want to edit /private/etc/ssh_config and to set up the following two values for the reasons that we have seen earlier:

RSAAuthentication no 
PasswordAuthentication no 

A Word About Time-out

Related Reading

SSH, The Secure Shell: The Definitive Guide
By Daniel J. Barrett, Richard E. Silverman

When acting over such long links, you should keep in mind that your connection goes through many devices that enforce various time-out policies. For example, your router may end NAT links after a few minutes of inactivity, without giving you the opportunity to alter the setting. It is therefore a good idea to avoid letting your connection be idle for more than a few seconds.

Indeed, should a device drop the connection while you are working, you not only may lose data but also may have difficulties establishing a new connection to the server.

A Special Note for FileVault Users

As we saw a few months ago, FileVault replaces your regular Home folder by a disk image that is mounted when you log in.

However, this means, quite logically, that as soon as you log out of your account, its contents are unmounted and cannot be accessed by any other process, including the SSH server. Therefore, the keys that you have just placed in your .ssh folder won't be available and authentication will systematically fail unless you are logged in locally.

There are ways around this, of course, one of them being to create a nonvaulted account, into which you would log in before mounting the .spaseimage that actually makes the vault. However, you should keep in mind that if the information you store on your computer is important enough to be vaulted, it is probably not a good idea to access it remotely that way and to type your FileVault password in a way that makes it more or less easy to get--depending on the method you pick. You may want to look into VPN solutions for high-security environments.

You can always put your keys into another folder, but this raises security issues of its own and is beyond the scope of our discussion.

Note that this is the case only on the server; you can FileVault your client without incident since, by definition, you will be logged in to the account when accessing the remote machine. Just make sure that your backups are in encrypted form too--or someone stealing your backup could access the contents of your home folder, including your keys.

Pages: 1, 2

Next Pagearrow