nvoked
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 advantageous 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.
You can
run multiple servers if you like, however. For example, you might run
both
5.2.1. Running as the Superuser
The SSH server is invoked by simply
typing its name:
# SSH1, SSH2, OpenSSH
$ 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
/etc/rc.local or the appropriate
startup file on your system. For example:
# Specify the path to sshd.
SSHD=/usr/local/bin/sshd
# If sshd exists, run it and echo success to the system console.
if [ -x "$SSHD" ]
then
$SSHD && echo 'Starting sshd'
fi
SSH2 comes with a sample SysV-style init control script, named
sshd2.startup.
5.2.2. Running as an Ordinary User
Any user can run
sshd,
provided that 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).
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, you must 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. [
Section 6.2, "Creating an Identity"] For now, to create a 1024-bit host key and
store it in the file
~/myserver/hostkey, type
the following for SSH1 or OpenSSH:
# SSH1, OpenSSH
$ ssh-keygen -N '' -b 1024 -f ~/myserver/hostkey
This command generates the files
hostkey and
hostkey.pub in the directory
~/myserver (so make sure the directory exists).
Here's the analogous command for SSH2:
# SSH2 only
$ ssh-keygen2 -P -b 1024 ~/myserver/hostkey
The
-P and
-N cause the generated
key to be saved in plaintext, because
sshd expects
to read it without prompting someone for a passphrase.
Third, you must 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.
[
Section 3.4.2.3, "Trusted-host authentication (Rhosts and RhostsRSA)"] 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 be causing trouble if you steal one.
Finally, you must create your own SSH server configuration file.
Otherwise, the server uses 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:
# SSH1, SSH2, OpenSSH
$ 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, it's useful to read the diagnostic
messages printed by the server, in case something isn't working
right. Unfortunately, your server's log messages are written to
the system log files, which you don't own and possibly
can't access. Because sshd does its logging
via the syslog service, an ordinary user can't control where
the log messages are sent. To see them, you need to locate the system
logs, which might be in /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. To get around this annoyance,
consider running the server in debug mode, so messages will appear on
your terminal (as well as in the system logs). [Section 5.8, "History, Logging, and Debugging"] 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.
