Serverwide Configuration

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

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: You might also consider disabling telnetd and other insecure avenues for logging in, permitting logins only via SSH.

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


/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: ["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. ["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