Section 10.2. SSH Server Configuration

10.2. SSH Server Configuration

In most cases, SSH is the preferred remote text-mode access method; this protocol implements security at its core, and it's become almost as widely available as Telnet. SSH is, though, a much more complex protocol, and its server program implementations reflect this fact. Configuring and running an SSH server is therefore a more complex task than configuring and running a Telnet server, although the default SSH server configurations for most Linux distributions require little work to get running.

10.2.1. SSH Server Options for Linux

If you want to use SSH, you must first decide which of several SSH server packages to use:

SSH Tectia

SSH was developed by a company called SSH Communications Security (http://www.ssh.com), which sells its commercial SSH server under the name SSH Tectia. (Versions prior to 4.0 used the name SSH alone.)

OpenSSH

This may be the most popular SSH server in Linux. It was originally developed in association with OpenBSD, but most Linux distributions include it under the package name openssh or something similar. Its official web site is http://www.openssh.org, and it's distributed under the BSD license.

FreSSH

This server, headquartered at http://www.fressh.org, is an independent SSH implementation that's distributed under the BSD license.

lsh

For GPL fans, lsh is an SSH implementation under that license. You can learn more at http://www.lysator.liu.se/~nisse/lsh/.

Any of these servers should work well and interoperate with common SSH client programs, but their configuration details differ. This chapter describes OpenSSH configuration, which is similar to SSH Tectia in its configuration file locations and formats. If you elect to use FreSSH or lsh, you need to consult your server's documentation. If you need more information on SSH than is in this chapter, consult the package's manpages or a book on the subject, such as SSH, The Secure Shell: The Definitive Guide (O'Reilly).

SSH has seen protocol version changes over time. As I write, SSH Version 2 is the latest major protocol release in widespread use. Older systems may require use of SSH Version 1, but its use isn't recommended. Major SSH servers should support both protocols, but configuration options are available to disable one or the other version.

10.2.2. Configuring an SSH Server

Once you've installed your SSH server package, you should look for its configuration file: /etc/ssh/sshd_config. Do not confuse this file with the configuration file for your SSH client program, /etc/ssh/ssh_config. This one-character difference in filenames can lead to a great deal of confusion if you don't notice it.

The OpenSSH configuration file format is fairly straightforward: non-comment lines begin with a keyword and end with an argument. Comment lines are denoted by a leading hash mark (#). For the most part, the default SSH configuration should work reasonably well for most installations; however, you might want to look through the file to be sure everything's set reasonably. Pay particular attention to these options:

AllowTcpForwarding

This option defaults to yes, which tells the server it may forward connections to ports specified by the client. This is a useful feature if you want to use SSH to tunnel other protocols. Disabling it might seem to be one way to improve security, but if users have shell access, they can install their own port forwarders, so disabling this feature isn't likely to provide any significant security benefit.

AllowUsers

You can provide a list of users who are given access by using this option. This may be a handy security tool if only some users should have remote access. (A similar option for groups is called AllowGroups.)

Banner

If you pass a filename to this option, OpenSSH displays its contents to the client before authenticating the user.

Compression

This option takes a yes or no argument, which tells the server whether to accept a client request to compress data transfers. The default value is yes, which is usually desirable; however, if your server has a weak CPU, you might want to set this value to no.

DenyUsers

This option is the opposite of AllowUsers; you can blacklist specific users by listing them as arguments. A similar option for groups is DenyGroups.

GatewayPorts

This option defaults to no, which causes remote port forwardings to bind only to the loopback address (127.0.0.1). For some tunneling applications, though, these forwards should bind to all local network addresses, which requires this option to be set to yes.

KerberosAuthentication

If set to yes, this option tells SSH to try to validate a user's password with the help of a Kerberos server. The default value is no.

ListenAddress

This option takes a hostname or IP address, optionally followed by a colon and a port number (as in 192.168.1.7 or 192.168.1.7:22) to specify the network hardware to which the server should bind. If this option is not specified, SSH binds to all network interfaces. To bind to multiple interfaces but not to all of them, you can provide multiple ListenAddress lines.

LogLevel

This option determines how much information the server logs. Possible values, in increasing log level, are QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, and DEBUG3, with the default being INFO.

PasswordAuthentication

This option, which defaults to yes, determines whether the system should accept passwords for authentication.

PermitRootLogin

This option tells SSH whether and under what circumstances to accept direct root logins. The default value is yes, but you may want to set this option to no to reduce the risk of abuse. (You can still log in as a normal user and run su, sudo, or other tools to administer a Linux system.) Intermediate values are without-password, which disables password-based authentication in favor of public key authentication, and forced-commands-only, which disables root logins but permits public key authentication only for running specific commands. That can be handy for enabling remote backups or other tasks that require running specific programs as root.

Protocol

You can tell SSH which protocol levels to support by passing their numbers. If you want to support both Versions 1 and 2, you must separate the numbers with a comma, as in 2,1. Order is unimportant; protocol preference is set by the client.

PubkeyAuthentication

This option takes a yes or no value and defaults to yes. It determines whether the server accepts public key authentication. This option affects SSH Version 2 only.

RSAAuthentication

This option is similar to PubkeyAuthentication, but if affects protocol Version 1 only. (SSH protocol Versions 1 and 2 require different public key file formats.)

UseDNS

If set to yes (the default), this option causes the server to look up a client's hostname using its IP address and then look up the IP address from that hostname and check that it matches the IP address the client uses. This improves security because it makes it harder for an attacker to pretend to be an authorized client, however, this option can also cause problems if your DNS configuration is broken or slow.

UsePAM

This option defaults to no, but you may need to change it to yes if you want to use an NT domain controller, LDAP server, or other advanced authentication tools, as described in Appendix A. If you do this, the documentation recommends also setting PasswordAuthentication to no.

X11Forwarding

This option, which defaults to no, tells SSH not to forward X traffic. This configuration helps protect the client's X server from attack; however, to use SSH as part of a remote X access method, as described in Chapter 11, you must change this option to yes.

SSH in general, and the OpenSSH server implementation in particular, is complex enough that this list is incomplete. If you need to perform more advanced tasks, you may need to consult the relevant documentation.

10.2.3. Launching an SSH Server

You can launch an SSH server using a super server, much as you launch a Telnet server; however, SSH is slower to start up than is Telnet, so the more common approach is to start SSH using a SysV or local startup script. Most Linux SSH packages include such a script, typically called ssh or sshd and stored in /etc/init.d or /etc/rc.d/init.d. To start or stop the SSH server on a one-time basis, pass the start or stop option to the SysV startup script, and most distributions respond with some sort of status report:

# /etc/init.d/sshd start  * Starting sshd...                      [ ok ]

Most distributions provide a tool called chkconfig to manage which servers start in common runlevels; to tell your system to start the SSH server, type a command such as chkconfig --add sshd. Consult distribution-specific documentation if this command doesn't work or if you need to perform other special tasks. Instead of chkconfig, Gentoo Linux uses rc-update; you'd type rc-update add sshd default to add the SSH server to the default runlevel.

Once the server is running, you should be able to access it from another computer:

$ ssh [e-mail] Password: Last login: Mon Dec 27 11:24:40 2004 from pointer.example.com Have a lot of fun... linnaeus@mandragora:~>

This example uses the username@hostname form of address to specify both the username and the server's hostname. In many cases, you can omit the username@ part, though; Linux's ssh clients use your current username if you don't specify one. To execute a single command rather than log into the remote system, specify the command after the other options, as in ssh [e-mail] shutdown now -r to shut down and reboot the remote computer. (Note that this particular example requires that direct root access be enabled.)