After installing an SSH server (sshd),[42] it's time to make informed decisions about your server's operation. Which authentication techniques should be permitted? How many bits should the server key contain? Should idle connections be dropped after a time limit or left connected indefinitely? These and other questions must be considered carefully. sshd has reasonable defaults, but don't accept them blindly. Your server should conform to a carefully planned security policy. Fortunately, sshd is highly configurable, so you can make it do all kinds of interesting tricks.
This chapter covers serverwide configuration, in which a system administrator controls the global runtime behavior of the SSH server. This includes a large, rich set of features, such as TCP/IP settings, encryption, authentication, access control, and error logging. Some features are controlled by modifying a serverwide configuration file, and others by command-line options passed to the server at invocation.
Serverwide configuration is just one of three levels for controlling the behavior of SSH servers. The other two levels are compile-time configuration (Chapter 4), in which the server is compiled with or without certain functionality; and per-account configuration (Chapter 8), in which the server's behavior is modified by end users for their accounts only. We'll discuss the distinction between the three levels in more detail later. [5.2]
This chapter covers only the OpenSSH and Tectia servers, focusing on the Unix implementations (including Unix variants such as Linux and OpenBSD). We've tried to indicate which features are present or absent in each flavor of sshd, but these will certainly change as new versions appear, so read each product's documentation for the latest information.
Ordinarily, an SSH server is invoked when the host computer is booted, and it is left running as a daemon. This works fine for most purposes. Alternatively, you can invoke the server manually. This is helpful when you're debugging a server, experimenting with server options, or running a server as a nonsuperuser. Manual invocation requires a bit more work and forethought but might be the only alternative for some situations.
Most commonly, a computer has just one SSH server running on it. It handles multiple connections by spawning child processes, one per connection.[43] You can run multiple servers if you like: for example, two copies of sshd listening on different TCP ports, or even several versions of sshd at once.
The SSH server is invoked by simply typing its name:
$ sshd
The server automatically runs in the background, so no ampersand is required at the end of the line.
To invoke the server when the host computer boots, add appropriate lines to an appropriate startup file on your system, such as /etc/rc.local on Linux. For example:
# Specify the path to sshd.
SSHD=/usr/local/sbin/sshd
# If sshd exists and is executable, run it and echo success to the system console.
if [ -x "$SSHD" ]
then
$SSHD && echo 'Starting sshd'
fiBoth OpenSSH and Tectia come with a startup or boot script (i.e., a System-V-style init control script) found in the appropriate directory for each Unix variant. For Linux, for example, the scripts are /etc/init.d/sshd for OpenSSH and /etc/init.d/sshd2 for Tectia.[44]
Any user can run sshd if several steps are completed beforehand:
Get permission from your system administrator.
Generate a host key.
Select a port number.
Create a server configuration file (optional but strongly recommended).
Before starting, ask your system administrator if you may run an SSH server. While this isn't necessary from a technical standpoint, it is a wise idea. An administrator might not appreciate your creating a new avenue for logins behind his back. Likewise, if the administrator has disabled SSH or certain SSH features, there's probably a good security reason and you shouldn't just work around it!
Next, generate your own host key. Any other existing host key is probably readable only by the superuser. Host keys are generated with the program ssh-keygen. [6.2] For now, to create a 1024-bit DSA host key and store it in the file ~/myserver/hostkey, type the following for OpenSSH:
# OpenSSH: Note the -N value is two single quotes, not a double-quote
$ ssh-keygen -N '' -b 1024 -t dsa -f ~/myserver/hostkeyThis command generates the files hostkey and hostkey.pub in the directory ~/myserver (so make sure the directory exists). Here's the analogous command for Tectia:
# Tectia
$ ssh-keygen -P -b 1024 -t dsa ~/myserver/hostkeyThe -N (OpenSSH) and -P (Tectia) options cause the generated key to be left unencrypted because sshd expects to read it without a passphrase.
Third, select a port number on which the SSH server listens for
connections. The port number is set with the -p
command-line option of sshd or the Port keyword in the configuration file, as
we discuss later. Your server can't listen on port 22, the default,
because only the superuser may run processes to listen on that port.
Your port number must be greater than or equal to 1024, as lower port
numbers are reserved by the operating system for use by privileged
programs. [3.4.3.6]
The port number also must not conflict with those in use by other
programs on the server computer; if it does, you get an error message
when you try to start the server:
error: bind: Address already in use
If you receive this error, try another integer in the free range (above 1024). Avoid numbers mentioned in the computer's services map (usually /etc/services or the Network Information Service [NIS] "services" map, which you can view with the Unix command ypcat -k services). These numbers have been designated by the system administrator for use with particular programs or protocols, so you might cause trouble if you steal one. The command netstat -a lists all ports in use; add the -n option to see numeric values for the ports instead of service names.
Finally, create your own SSH server configuration file. Otherwise, your server will use built-in defaults or a systemwide configuration file (if one exists) and might not operate as you intend.
Assuming you have generated a host key in ~/myserver/hostkey, selected the port number 2345, and created a configuration file in ~/myserver/config, the server is invoked with the command:
$ sshd -h ~/myserver/hostkey -p 2345 -f ~/myserver/config
A server run by an ordinary user has some disadvantages:
It runs under the uid of the ordinary user, not root, so it can connect only to that user's account.
It is invoked manually, rather than automatically when the computer boots. As a result, to run the server, you must connect once without SSH to the computer. And each time the computer is rebooted, the server dies, and you need to redo this step. Conceivably you can set up a cron job to keep it running automatically.
While setting up a server, consider running it in debug mode and reading the diagnostic messages it prints, in case something isn't working right. By default, your server's log messages are written to the system log files, which you don't own and possibly can't access. This is because sshd does its logging via the syslog service; ordinary users can't control where the log messages are sent, usually /var/adm/messages, /var/log/messages, or someplace else depending on how syslogd is set up, and you need appropriate permissions to read these files. Running the server in debug mode gets around this annoyance. Messages will appear on your terminal (as well as in the system logs). [5.9] This way, you can more easily see error messages until you get the server working.
Nevertheless, for many users, the advantages of SSH outweigh these inconveniences. Assuming your system administrator approves, you can secure your logins with sshd even if you aren't a superuser.
[42] Tectia's server might also be named sshd2, with sshd being a symbolic link to sshd2. See the upcoming sidebar "Tectia's File-Naming Conventions."
[44] OpenSSH also includes /usr/sbin/rcsshd, a symbolic link to the startup script in /etc/init.d.