10.3. Serverwide ConfigurationChapter 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 AccessSSH 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:
10.3.2. /etc/sshd_configWe'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.
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).HostKey /etc/ssh_host_key PidFile /etc/sshd.pid RandomSeed /etc/ssh_random_seed
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.StrictModes yes Umask 0077
For logins we allow 30 seconds for a successful authentication, which should be long enough for users and automated processes:Port 22 ListenAddress 0.0.0.0 IdleTimeout 15m KeepAlive yes
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).LoginGraceTime 30
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.ServerKeyBits 768 KeyRegenerationInterval 3600
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):PasswordAuthentication no RhostsAuthentication no RhostsRSAAuthentication no RSAAuthentication 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.)IgnoreRhosts yes IgnoreRootRhosts yes
The following settings limit access to the server, permitting SSH connections only from within the local domain (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.UseLogin no
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 220.127.116.11, "Account access control"]
AllowHosts fred@* *.your.domain.com Just an example
We permit the superuser to connect via SSH but not by password authentication. This is redundant but consistent with turning off PasswordAuthentication.SilentDeny yes
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.PermitRootLogin nopwd
We permit TCP port forwarding and X forwarding so users can secure their other TCP connections:FascistLogging no QuietMode no
AllowTcpForwarding yes X11Forwarding yes
10.3.3. /etc/ssh2/sshd2_configWe 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:
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)"]HostKeyFile /etc/ssh2/hostkey PublicHostKeyFile /etc/ssh2/hostkey.pub RandomSeedFile /etc/ssh2/random_seed
For this setting, see the discussion for SSH1:UserConfigDirectory IdentityFile AuthorizationFile
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 18.104.22.168, "Reverse IP mappings"]StrictModes yes
For this setting, see the discussion for SSH1:Port 22 ListenAddress 0.0.0.0 KeepAlive yes RequireReverseMapping no
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:LoginGraceTime 30
These settings mirror those for SSH1:$ sshd2 -b 1024 ...
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.AllowedAuthentications publickey RequiredAuthentications publickey
See the discussion for SSH1 about this setting:IgnoreRhosts yes UserKnownHosts no
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.PermitRootLogin nopwd
The following settings produce enough logging information to be useful:Ciphers anycipher Ciphers anystdcipher
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.QuietMode no VerboseMode yes
Ssh1Compatibility no #Sshd1Path /usr/local/bin/sshd1 # commented out
Copyright © 2002 O'Reilly & Associates. All rights reserved.