have SSH packages available. If possible, use OpenSSH (http://www.openssh.com/)–it's developed by the OpenBSD team, and is quickly becoming the most popular implementation of SSH.

If you're running a Microsoft operating system, I recommend MindTerm (though I've also had strong recommendations for Putty and Terraterm). MindTerm is free for noncommercial use, supports both SSH1 and SSH2, and is written in Java, which means that it will run on any platform that has a Java virtual machine (JVM). (Most Web browsers include a JVM.) The MindTerm documentation will have you running with an SSH client in just a few minutes. A quick Web search will lead you to any of the three, and any one will almost certainly fit your needs.

Connecting via SSH

To connect to another host with FreeBSD's ssh client, type ssh hostname. In response, you should see something like this:

...............................................................................................

# ssh moneysink.blackhelicopters.org

The authenticity of host 'moneysink' can't be established.

RSA key fingerprint is 7c:07:0f:1e:74:1a:42:11:b9:08:41:e4:f3:c9:05:a7. Are you sure you want to continue connecting (yes/no)? yes

...............................................................................................

Your client does two things immediately. One, it retrieves the public key from the remote host. Two, it checks its own list of SSH keys for a key for that host. If the client has the host key in its list, and the host key retrieved from the remote host matches it, the client assumes you're actually talking to the correct host. If the client doesn't have the host key in its list of known hosts, it presents the key fingerprint for your approval.

You can decide whether to accept or reject the connection upon seeing the key; the fingerprint you see should be identical to the fingerprint you created on the remote host. If the fingerprint isn't identical, you're either talking to the wrong host or you have a fingerprint for the wrong version of SSH. Compare the fingerprint we created to the fingerprint the remote host is offering–if it matches, this is the same host. Once you accept the key, it is saved in your ~/.ssh/known−hosts (for SSH1) or ~./.ssh/known−hosts2 (for SSH2) file.

It's not always worth the time to manually compare keys. If you're building a new server on your local network for your use only, perhaps you don't have to. (You should still copy the fingerprint, however, since you'll eventually want to connect from some remote location and will need to be able to verify the key.) If many people will be connecting to this server, it's generally okay to put the fingerprints on a Web page somewhere. Whatever the case may be, you'll need to decide how much secrecy you'll need.

Configuring SSH

All of the files for systemwide configuration of SSH are kept in /etc/ssh, and we'll consider them one at a time.

Note Because the defaults for SSH change slowly over time, as the Internet's general security stance tightens, I won't give the defaults for each setting. See the appropriate files on your system to see how it is configured.

306

/etc/ssh/ssh_config

The /etc/ssh/ssh_config file controls the default operation of the ssh client. While users can override the settings in this file with either their own private ~./.ssh/config files or command−line options, this gives the administrator the opportunity to provide reasonable defaults.

Note Anything you set as the client can be overridden by the server. For example, though you might request X11 forwarding, if the server doesn't offer that feature, you cannot use it.

ForwardX11 yes X applications can display on any machine, not just the one they're running on. If you want to run X applications on a remote machine and have the display forwarded back to your workstation, set this to yes.

RhostsAuthentication yes If the user's account on the remote server has a .rhosts file listing the local machine, trust it. This is almost always disabled by the server, for good reason; in fact, I cannot think of a single good reason to use this setting.

FallBackToRsh no If an ssh connection attempt fails, the ssh client will attempt to open an rsh connection instead, which is insecure. If you can't connect safely, don't connect at all—there's probably a good reason why you can't connect! If you set FallBackToRsh to no, the rsh attempt will not be made.

CheckHostIP yes With this option enabled, the ssh client will automatically compare the IP address of the server with the IP address given in the .ssh/known_hosts file. This helps detect IP spoofing and changed IP addresses. Set this to no to disable this check.

StrictHostKeyChecking no This option is for the particularly paranoid. If set to no, the ssh client will refuse to connect to a host whose key is not in ./.ssh/known_hosts. It will also refuse to add new hosts to the known_hosts file; you will have to add them manually.

Port 22 This is the default port to connect to on the remote host. You can change this to provide some security through obscurity, but it's generally not worth it.

Protocol 2,1 This option specifies the order in which the SSH protocols are offered to a client. You can disable a protocol by not including it on the list.

Cipher blowfish SSH can use either the 3DES or Blowfish protocols. While Blowfish is faster, it's also newer, and in the cryptography world newer does not automatically mean better! Still, Blowfish has resisted cryptanalysis so far, and has a promising future. The default is 3DES.

/etc/ssh/ssh_host_key and /etc/ssh/ssh_host_dsa_key These files contain the system's private SSH cryptographic keys and are readable only by root. The DSA file is for SSH2, the other is for SSH1.

/etc/ssh/ssh_host_key.pub and /etc/ssh/ssh_host_dsa_key.pub These are the world−readable cryptographic keys for this system. Public−key cryptographic systems will combine this public key with the private key and generate a unique numerical fingerprint. Again, the DSA file is for SSH2, the other is for SSH1.

/etc/ssh/sshd_config The /etc/ssh/sshd_config file describes the services your SSH daemon offers to other hosts. While a client can request any protocol or service that they like, the server has the

307

final word. This allows the system administrator to permit actions he doesn't care about while rejecting the unacceptable.

The following sections describe the keywords the file contains.

AllowGroups By default, anyone with a legitimate shell can log in to the server, but with this option set, only users in the specified groups can log in. Groups are created in /etc/group (see Chapter 9). To specify groups, list each on a single line, separated by spaces. (While you can use an asterisk

(*) as a wildcard, you cannot use numerical GIDs.) The group listed must be the user's primary group–the group shown in /etc/passwd.

AllowTcpForwarding Users with SSH access can encrypt any traffic between any two hosts. Set this to no to prevent this. If a user has shell access, however, she could install her own TCP port forwarder and get around this.

AllowUsers This option allows you to explicitly list users who are allowed to use this SSH server. By default, any user can log in.

Ciphers If you're cryptographically literate, you can choose the order in which cryptographic algorithms are tried. List them all on a single line, separated by commas. If you know little or nothing about cryptography, use the defaults.

DenyGroups This is the opposite of the AllowGroups option explained earlier; users in this system group cannot log in. The listed group must be their primary group, meaning it must be listed in /etc/passwd and not just /etc/group.

IgnoreRhosts yes The .rhosts files are left over from the days when rlogin and rsh were accepted UNIX standards. While they might be useful during a migration from rsh to ssh, they're generally obsolete and dangerous. To allow the use of .rhosts files, set this to no.

KeepAlive OpenSSH checks the status of idle connections every so often. If the other end cannot be reached, the session is disconnected and cleaned up. This check is called a "keepalive." A transient network problem can cause an SSH session to disconnect if you're using keepalives. To keep your SSH session open if at all possible, set this to no. Without keepalives, though, you can leave orphaned SSH sessions lying around for weeks on end–your end of the connection may never realize that the computer on the other end has been rebooted or has even burst into flame. Using keepalives is generally recommended.

PasswordAuthentication This option controls how users are allowed to use passwords to log in. It's more secure to use RSA or DSA cryptographic authentication, but most people aren't set up to do that. (Yet.) For now, set this to yes. We won't discuss RSA and DSA authentication here.

PermitEmptyPasswords no This is almost exactly as bad as it sounds. Don't set it to yes. Really. Trust me on this one.

PermitRootLogin no This option controls whether someone can directly log in as root via SSH. It's far wiser to have people SSH in as themselves, and use su(8) to become root. That way, when your system is cracked, you have a fighting chance to identify whose account was used, and at least have someone to blame. It won't help the problem, but it might make you feel better.

UseLogin If you set this to yes, then sshd will interoperate with the login(1) program. This permits the use of login.conf and all the other nifty login tweaks described in Chapter 9.

308