Serverwide Configuration (SSH, The Secure Shell: The Definitive Guide)

10.3. Serverwide Configuration

Chapter 5, "Serverwide Configuration" was a detailed discussion of sshd and how to configure its runtime behavior. Now let's determine which configuration options are most important for security.

10.3.1. Disable Other Means of Access

SSH can provide a secure front door into your system but don't forget to close the back doors. If your system allows access via the infamous r-commands, disable them. This means:

Remove the file /etc/hosts.equiv, or make it a read-only empty file.
Disable rshd, rlogind, and rexecd by removing or commenting out their lines in /etc/inetd.conf
:
```
# turned off -- don't use!
#shell   stream  tcp   nowait  root  /usr/sbin/in.rshd     in.rshd
```
Make sure you restart inetd after doing this, so that the change takes effect (e.g., skill-HUP inetd ).
Educate users not to create .rhosts files.

You might also consider disabling telnetd and other insecure avenues for logging in, permitting logins only via SSH.

10.3.2. /etc/sshd_config

We'll now discuss our recommended sshd_config settings. We have omitted some keywords that aren't particularly security-related, such as PrintMotd, which simply prints a message after login. For any remaining keywords, use your judgment based on your system and needs.

The following files may be located anywhere on the machine's local disk. For security's sake, don't put them on an NFS-mounted partition. If you do, each time the files are accessed by the SSH server, their contents are transmitted in the clear over the network.

HostKey /etc/ssh_host_key
PidFile /etc/sshd.pid
RandomSeed /etc/ssh_random_seed

The following settings control file and directory permissions. The StrictModes value requires users to protect their SSH-related files and directories, or else they can't authenticate. The Umask value causes any files and directories created by sshd1 to be readable only by their owner (the uid under which sshd is running).

StrictModes yes
Umask 0077

The following code represents the server's TCP settings. The Port and ListenAddress values are standard. We set an idle timeout to reduce the chances that an unattended terminal can be misused by an intruder. Fifteen minutes is short enough to be useful but long enough not to annoy users, though this depends on usage patterns. You may certainly use your judgment and set a different value, but do think about the issue. Also, we enable keepalive messages so connections to clients that have crashed or otherwise become unreachable will terminate rather than hang around and require manual reaping by the sysadmin.

Port 22
ListenAddress 0.0.0.0
IdleTimeout 15m
KeepAlive yes

For logins we allow 30 seconds for a successful authentication, which should be long enough for users and automated processes:

LoginGraceTime 30

The following settings control generation of the server key. We recommend at least 768 bits in your server key and that you regenerate the key at least once an hour (3600 seconds).

ServerKeyBits 768
KeyRegenerationInterval 3600

The following settings control authentication, and we enable only public-key authentication. Password authentication is disabled because passwords can be stolen and used more easily than public keys. This is a fairly harsh restriction, so you might want to leave it enabled depending on your needs. Without password authentication, you have a "chicken and egg" problem: how do users upload their public keys securely the first time? As system administrator, you have to institute a process for this transfer: for example, users can generate keys on a client machine and then request that you install them on the server machine. Rhosts authentication is disabled because it can be spoofed. RhostsRSA authentication is disabled too, because overall it is a medium-security method and this configuration is on the side of higher security.

PasswordAuthentication no
RhostsAuthentication no
RhostsRSAAuthentication no
RSAAuthentication yes

Although we've disabled trusted-host authentication already, we still forbid sshd to use .rhosts files at all (just in case you reenable trusted-host authentication):

IgnoreRhosts yes
IgnoreRootRhosts yes

UseLogin is disabled to prevent the unlikely but unwanted use of an alternative login program. (This isn't very useful. An intruder who can install an alternative login program probably can also edit sshd_config to change this line.)

UseLogin no

The following settings limit access to the server, permitting SSH connections only from within the local domain [128] (except for the account fred, which may receive connections from anywhere). If you want to restrict access to particular local accounts or Unix groups, add AllowUsers and AllowGroups lines (or DenyUsers and DenyGroups). We have set SilentDeny so that any rejections by DenyHosts produce no messages for the user. No sense in giving an intruder a clue about what happened, although this can make troubleshooting more difficult.

[128]The reliability of this restriction depends on the integrity of DNS. Unfortunately, due to the implementation of AllowHosts, restriction by IP address is no more secure. [Section 5.5.2.1, "Account access control"]

AllowHosts fred@* *.your.domain.com              Just an example

SilentDeny yes

We permit the superuser to connect via SSH but not by password authentication. This is redundant but consistent with turning off PasswordAuthentication.

PermitRootLogin nopwd

For logging error messages, we disable FascistLogging because it writes user-specific information to the log, such as the dates and times each person logged in. This information can be valuable to an intruder. We disable QuietMode, however, to receive more detailed (but less sensitive) log messages.

FascistLogging no
QuietMode no

We permit TCP port forwarding and X forwarding so users can secure their other TCP connections:

AllowTcpForwarding yes			
X11Forwarding yes

10.3.3. /etc/ssh2/sshd2_config

We now move to our recommended sshd2_config settings. Again, we omitted some keywords that are not security-related.

As we have mentioned before, make sure all SSH-related files are on local disks, not remotely mounted partitions:

HostKeyFile /etc/ssh2/hostkey
PublicHostKeyFile /etc/ssh2/hostkey.pub
RandomSeedFile /etc/ssh2/random_seed

For the following settings, consider the pros and cons of storing user files on NFS-mounted filesystems: [Section 10.7, "Remote Home Directories (NFS, AFS)"]

UserConfigDirectory
IdentityFile
AuthorizationFile

For this setting, see the discussion for SSH1:

StrictModes yes

For the first three settings, use the same reasoning as for SSH1. RequireReverseMapping is trickier, however. You might think that security would be increased by reverse DNS lookups on incoming connections, but in fact, DNS isn't secure enough to guarantee accurate lookups. Also, due to other issues in your Unix and network environment, reverse DNS mappings might not even work properly. [Section 5.4.3.7, "Reverse IP mappings"]

Port 22
ListenAddress 0.0.0.0
KeepAlive yes
RequireReverseMapping no

For this setting, see the discussion for SSH1:

LoginGraceTime 30

In addition, since sshd2 doesn't have a configuration keyword for the number of bits in the server key, run it with the -b option:

$ sshd2 -b 1024 ...

These settings mirror those for SSH1:

AllowedAuthentications publickey
RequiredAuthentications publickey

You disable UserKnownHosts to prevent users from extending trust to unknown hosts for the purpose of trusted-host authentication. The superuser can still specify trusted hosts in /etc/ssh2/knownhosts.

IgnoreRhosts yes
UserKnownHosts no

See the discussion for SSH1 about this setting:

PermitRootLogin nopwd

Use either of the following settings as fits your needs. The notable feature is that they both exclude the none cipher which, as discussed for -- without-none, may be a security risk.

Ciphers anycipher
Ciphers anystdcipher

The following settings produce enough logging information to be useful:

QuietMode no
VerboseMode yes

Since SSH-2 is a more secure protocol, we have disabled SSH-1 compatibility mode. However, this may not be an option for practical reasons; if you turn it on, set Sshd1Path to the pathname of your SSH1 server executable.

Ssh1Compatibility no
#Sshd1Path /usr/local/bin/sshd1   # commented out


10.2. Compile-Time Configuration		10.4. Per-Account Configuration