Running the Server

Ordinarily, an SSH server is i 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.[55] You can run multiple servers if you like, however. For example, you might run both sshd1 and sshd2, or several versions of a server, each listening on a different TCP port.

[55]Or sshd can be invoked by inetd, creating one sshd process per connection. ["Invocation by inetd"]

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.

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. ["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. ["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). ["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.