Serverwide Configuration

Chapter 5 provided 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:

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

10.3.2 sshd_config for OpenSSH

We'll now discuss our recommended sshd_config settings for OpenSSH. 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.

We recommend disabling the SSH-1 protocol altogether:

    # OpenSSH
    Protocol 2

Important files containing your host key, PID, and so on, 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.

    # OpenSSH
    HostKey /etc/ssh/ssh_host_key
    PidFile /var/run/sshd.pid

The StrictModes value requires users to protect their SSH-related files and directories, or else they can't authenticate.

    # OpenSSH
    StrictModes yes

The Port and ListenAddress values we recommend are standard. Also, we enable keepalive messages so that connections to clients that have crashed or otherwise become unreachable will terminate rather than hang around and require manual reaping by the sysadmin.

    # OpenSSH
    Port 22
    ListenAddress 0.0.0.0
    TcpKeepAlive yes

We also disable reverse DNS lookups on incoming connections:

    # OpenSSH
    UseDNS no

You might think security is increased by reverse DNS lookups, 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. [5.3.3.8] Finally, SSH connections can be tremendously slowed down or fail altogether if the client's DNS is hosed (e.g., lots of nameservers, all unresponsive, so sshd times out). The IP addresses of connecting hosts end up in your logs anyway, so you can look them up later.

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

    # OpenSSH
    LoginGraceTime 30

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.

    # OpenSSH
    PubkeyAuthentication yes

    PasswordAuthentication no
    PermitEmptyPasswords no               Already disabled, but we're being paranoid
    RSAAuthentication no
    RhostsRSAAuthentication no
    HostbasedAuthentication no
    KerberosAuthentication no             Optional
    ChallengeResponseAuthentication no    Optional
    GSSAPIAuthentication no               Optional

We optionally disable Kerberos, keyboard-interactive, and GSSAPI authentication, even though they are quite secure, under the "keep it simple" principle: disable what you aren't using. Most SSH users aren't set up to use these techniques. Reenable them if your server needs to support them.

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

    # OpenSSH
    IgnoreRhosts yes
    IgnoreRootRhosts yes

If you want to restrict access to particular local accounts or Unix groups, add AllowUsers and AllowGroups lines (or DenyUsers and DenyGroups). We recommend creating a group for all your system's SSH users, called "ssh", and configuring the server with:

    AllowGroups ssh

Now you've made SSH access a specific privilege to be granted or revoked, and you can easily do it for a user without changing the sshd configuration:

    # usermod -G ssh,... joe         Add user joe to the SSH group

As a bonus, you've disallowed SSH access by system accounts like bin, sys, and daemon that should never use SSH anyway.

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

    # OpenSSH
    PermitRootLogin without-password

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

    # OpenSSH
    AllowTcpForwarding yes
    X11Forwarding yes

Confirm that the SFTP subsystem is defined so that incoming sftp connections will work. (It is enabled in the default /etc/ssh/sshd_config file for OpenSSH.)

    # OpenSSH
    Subsystem    sftp    /usr/lib/ssh/sftp-server

10.3.3 sshd2_config for Tectia

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

We recommend disabling the SSH-1 protocol altogether:

    # Tectia
    Ssh1Compatibility no
    Sshd1Path /dev/null      Not strictly necessary, just our paranoia

As we have mentioned for OpenSSH [10.3.2.2], make sure all SSH-related files are on local disks, not remotely mounted partitions:

    # Tectia
    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: [10.7]

    # Tectia
    UserConfigDirectory directory
    IdentityFile filename
    AuthorizationFile filename

The StrictModes value requires users to protect their SSH-related files and directories, or else they can't authenticate:

    # Tectia
    StrictModes yes

We recommend the same configuration as for OpenSSH, for the same reasons: [10.3.2.4]

    # Tectia
    Port 22

    ListenAddress 0.0.0.0
    KeepAlive yes
    RequireReverseMapping no

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

    # Tectia
    LoginGraceTime 30

These settings mirror those for OpenSSH:

    # Tectia
    AllowedAuthentications publickey
    RequiredAuthentications publickey          Overrides AllowedAuthentications; we're being paranoid
    PermitEmptyPasswords no                    Already disabled, but we're being paranoid

Although we've disabled hostbased authentication already, we still forbid sshd to use .rhosts files at all (just in case you reenable hostbased authentication). We also disable UserKnownHosts to prevent users from extending trust to unknown hosts for the purpose of hostbased authentication. The superuser can still specify trusted hosts in /etc/ssh2/knownhosts.

    # Tectia
    IgnoreRhosts yes
    IgnoreRootRhosts yes
    UserKnownHosts no

We permit SSH connections only from within the local domain[140]:

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

except for the account fred in this example, 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 ). Also create an "ssh" group as we described earlier. [10.3.2.7]

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

    # Tectia
    PermitRootLogin nopwd

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

    # Tectia
    AllowTcpForwarding yes
    X11Forwarding yes

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

    # Tectia
    Ciphers anycipher
    Ciphers anystdcipher

Confirm that the SFTP subsystem is defined so that incoming sftp connections will work. (It is enabled in the default /etc/ssh2/sshd2_config for Tectia.)

    # Tectia
    subsystem-sftp   sftp-server

[140] 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. [5.5.1]