Configuring SSH

You can run an SSH server via SysV startup scripts, local startup scripts, or a super server. (Chapter 22, "Running Servers," describes these methods of starting servers.) The SSH server must perform some encryption computations whenever it starts, so running the server from a super server can cause brief delays when connecting to the server. These delays are more noticeable with older CPUs than with modern ones. All of the major Linux distributions, except Slackware, launch SSH via SysV startup scripts. Slackware launches the server using the /etc/rc.d/rc.sshd script, which is called from /etc/rc.d/rc.inet2. After you make a change to the SSH configuration, you should tell the server to reread its configuration file. The ssh or sshd SysV startup scripts accept a reload option to do this job.

The SSH server is configured through the /etc/ssh/sshd_config file, and the SSH client is configured through the /etc/ssh/ssh_config file. These filenames are very similar, so be sure not to confuse them! Both files consist of comments (indicated by hash marks, #) and keyword/argument pairs, such as:

PermitRootLogin no

For the most part, both the client and server configurations are reasonable with most distributions. You might want to change a few options, though. Table 26.1 summarizes some SSH server options (in sshd_config) that you might want to change, and Table 26.2 summarizes some SSH client options (in ssh_config) you might want to change. Pay particular attention to the PermitRootLogin server option and to the X forwarding options on both the client and the server. As described in the upcoming section, "Tunneling X through SSH," using SSH to initiate a connection that supports X-based applications can be a convenient method of remote GUI access, but this configuration requires support in the client and server.

Table 26.1: Common SSH Server Configuration Options

Keyword

Argument Type

Description

Protocol

Integer

SSH protocol version number. OpenSSH 3.6.1 supports versions 1 and 2. To specify both versions, separate them with a comma, as in Protocol 1,2.

ListenAddress

Hostname or IP address and optional port number

Binds the server to listen only to the network interface associated with the specified address. If a port number is specified, it follows the address and a colon, as in ListenAddress 172.26.7.3:22. (The default SSH port number is 22.)

PermitRootLogin

Boolean, without-password, or forced-commands-only

Whether or not to accept direct logins as root. This option defaults to yes. Changing it to no will improve your system's security by requiring intruders to log in using an ordinary account and then using su, thereby requiring two passwords. The without-password option disables password authentication, meaning that another authentication method must be available. This option does not mean that users can log into the root account without any authentication. The

Keyword

Argument Type

Description forced-commands-only option enables public key authentication only for running commands remotely, which may be useful for performing remote backups or the like.

RhostsAuthentication

Boolean

If set to yes, the server accepts authentication based on the rhosts trusted-hosts authentication model for protocol level 1 sessions. This authentication method is inherently dangerous, as described in the upcoming sidebar, "Just Say 'No' to rlogin"," so I strongly recommend you leave this option at its default value of no.

RsaAuthentication

Boolean

If set to yes (the default), the server accepts Rivest/Shamir/Adleman (RSA) authentication for protocol level 1 sessions. This approach can improve security or eliminate the need to type a password, depending on how it's configured.

Keyword

Argument Type

Description

PubkeyAuthentication

Boolean

If set to yes (the default), the server accepts public

Keyword

Argument Type

Description key authentication for protocol level 2 sessions. This approach can improve security or eliminate the need to type a password, depending on how it's configured.

AuthorizedKeysFile

Filename

Name of the file in which clients' keys for public key authentication are stored.

KerberosAuthentication

Boolean

If set to yes, this option enables SSH to accept Kerberos tickets and to authenticate users via a Kerberos server. This option is useful if your network uses Kerberos, but is set to no by default. Additional options that begin with Kerberos can fine-tune the configuration; consult the sshd_config man page for details.

X11 Forwarding

Boolean

If set to yes, this option enables the server to forward X session data, as described in the upcoming section, "Tunneling X through SSH." The default value is no.

Compression

Boolean

If set to yes (the default), the server accepts requests from the client to enable compression. This

Keyword

Argument Type

Description

option consumes CPU

time but reduces network

bandwidth use.

Table 26.2: Common SSH Client Configuration Options

Keyword

Argument Type

Options

Protocol

Integer

This option works much like its namesake in the SSH server configuration file. The protocol levels are tried in the order specified.

ForwardX11

Boolean

If set to yes, the SSH client authorizes forwarding of X session data. The default is no. This option is similar to the X11 Forwarding option in the server configuration, but it is named differently.

Compression

Boolean

This option works much like its namesake in the SSH server configuration file, except that the default value is no.

CompressionLevel

Integer

Specify a value for how much compression you want to apply. A value of 1 is fast but compresses data little; a value of 9 is slow but achieves higher compression ratios. The default value is 6.

0 0

Post a comment