sshd_config: A Comprehensive Guide to SSH Server Configuration

Learn about every configuration option in the sshd_config file, and how to customize your SSH server for improved security and functionality.

The sshd_config file is a configuration file for the OpenSSH server (sshd), which is responsible for allowing secure remote access to a system via the SSH protocol. This file contains various settings and options that can be used to customize the behavior of the SSH server.

In this blog post, we'll go through each of the configurations available in the sshd_config file and explain what they do.

Port

This one is quite obvious, of course! 😉

The Port setting specifies the TCP port number on which the SSH server listens for incoming connections. By default, SSH servers listen on port 22, but you can choose a different port number to avoid conflicts with other services or to improve security by making the server less predictable to attackers.

I recommend using a port number between 20,000 and 50,000 for increased security. These ports are less likely to be targeted by scanners, and there is a chance that data center firewalls may block them after multiple attempts, further enhancing the security of your system.

ListenAddress

The ListenAddress setting specifies the IP address or hostname on which the SSH server listens for incoming connections. By default, the server listens on all available network interfaces, but you can restrict it to listen on specific IP addresses or hostnames. This can be useful for security reasons or to prevent conflicts with other services.

Example values:

  • 0.0.0.0 (listen on all addresses)
  • 192.168.1.100, example.com.

Protocol

The Protocol setting specifies the version of the SSH protocol to use. The default is version 2, which is more secure than the older version 1. Unless you have a specific reason to use version 1, it's generally recommended to stick with version 2.

Example values:

  • 1 (deprecated)
  • 2 (default)

HostKey

The HostKey setting specifies the location of the SSH server's host key files. These keys are used to authenticate the server to clients and ensure that encrypted connections are secure. By default, SSH server has three host keys (RSA, DSA, and ECDSA), but you can use only one or two of them if you prefer.

Example values:

  • /etc/ssh/ssh_host_rsa_key
  • /etc/ssh/ssh_host_ecdsa_key

KeyRegenerationInterval

The KeyRegenerationInterval setting specifies the interval at which the SSH server regenerates its server keys. This can help improve security by limiting the amount of time an attacker has to capture and crack the server's keys. The default interval is 1 hour, but you can adjust it to your liking.

Example values:

  • 1h (1 hour)
  • 1d (1 day)

ServerKeyBits

The ServerKeyBits setting specifies the length of the SSH server's host key in bits. Longer keys are more secure but require more processing power to encrypt and decrypt data. The default key length is 2048 bits, but you can increase it if you want to improve security. 🙃

Example values:

  • 1024
  • 2048 (default)
  • 4096

LoginGraceTime

The LoginGraceTime setting specifies the amount of time a user has to log in after connecting to the SSH server. If the user fails to log in within this time, the server terminates the connection. This can help prevent brute-force attacks by limiting the amount of time an attacker has to guess passwords.

Example values:

  • 1m (1 minute)
  • 2m30s (2 minutes and 30 seconds)

PermitRootLogin

The PermitRootLogin setting specifies whether the root user is allowed to log in to the SSH server directly. Allowing root login can be a security risk, as it gives an attacker full access to the system. ðŸĪŠ

It's generally recommended to disable root login and use a separate user account with sudo privileges instead.

Example values:

  • yes (default)
  • no

StrictModes

The StrictModes setting specifies whether the SSH server enforces strict file permissions for user home directories and the files within them. Enabling this option can improve security by preventing unauthorized access to sensitive files.

Example values:

  • yes (default)
  • no

MaxAuthTries

The MaxAuthTries setting specifies the maximum number of authentication attempts allowed per connection. After this many attempts, the server terminates the connection. This can help prevent brute-force attacks by limiting the number of guesses an attacker can make.

Example values:

  • 3 (default)
  • 5
  • 10

MaxSessions

The MaxSessions setting specifies the maximum number of SSH sessions that can be active simultaneously for a single user. This can help prevent resource exhaustion and limit the impact of compromised user accounts.

Example values:

  • 10
  • 20
  • unlimited

PubkeyAuthentication

The PubkeyAuthentication setting specifies whether public key authentication is allowed for SSH connections. Public key authentication is generally considered more secure than password authentication, as it eliminates the need to transmit passwords over the network.

Example values:

  • yes (default)
  • no

AuthorizedKeysFile

The AuthorizedKeysFile setting specifies the location of the file containing public keys for authorized users. This file is used for public key authentication, and it can be customized to allow or deny access for specific users or groups.

Example values:

  • ~/.ssh/authorized_keys (default)
  • /etc/ssh/authorized_keys/%u

PasswordAuthentication

The PasswordAuthentication setting specifies whether password authentication is allowed for SSH connections. Password authentication can be less secure than public key authentication because passwords can be guessed or intercepted.

Example values:

  • yes (default)
  • no

PermitEmptyPasswords

The PermitEmptyPasswords setting specifies whether empty passwords are allowed for user accounts. Allowing empty passwords can be a security risk, as it makes it easier for an attacker to gain unauthorized access to the system.

Example values:

  • no (default)
  • yes

ChallengeResponseAuthentication

The ChallengeResponseAuthentication setting specifies whether challenge-response authentication is allowed for SSH connections. When this option is enabled, the SSH server will require that clients respond to a challenge before allowing them to authenticate. This challenge-response mechanism is typically used as an additional layer of security to protect against brute-force attacks, where an attacker tries to guess a user's password by repeatedly submitting login attempts.

It's worth noting that ChallengeResponseAuthentication is enabled by default in some SSH server implementations, but it may be disabled for security reasons on some systems. Additionally, some SSH clients may not support challenge-response authentication, so it's important to ensure that the client and server are compatible if this option is enabled.

Example values:

  • yes (default)
  • no

UsePAM

The UsePAM setting specifies whether the SSH server should use the Pluggable Authentication Modules (PAM) framework for user authentication. PAM provides a flexible and extensible authentication system, allowing administrators to configure a wide range of authentication methods.

Example values:

  • yes (default)
  • no

AllowTcpForwarding

The AllowTcpForwarding setting specifies whether TCP forwarding is allowed for SSH connections. TCP forwarding allows clients to create TCP connections to other hosts through the SSH server, which can be useful for accessing remote services. However, it can also be a security risk if not properly configured.

Example values:

  • yes (default)
  • no

X11Forwarding

The X11Forwarding setting specifies whether X11 forwarding is allowed for SSH connections. X11 forwarding allows clients to run graphical applications on the remote server and display the output on the client's local display.

X11 forwarding can be useful for running graphical applications on remote servers, especially when the client machine does not have the necessary software installed. However, it is important to note that X11 forwarding can also be a security risk, as it can potentially allow an attacker to capture X11 traffic and steal sensitive information.

To mitigate this risk, it is recommended to only enable X11 forwarding when it is necessary, and to restrict it to trusted clients only. This can be done by specifying the AllowUsers or AllowGroups options (We will talk more about these later on this post 🙂) in the sshd_config file, or by using SSH key-based authentication to restrict access to authorized users only.

Example values:

  • yes (default)
  • no

AllowAgentForwarding

The AllowAgentForwarding setting specifies whether agent forwarding is allowed for SSH connections. Agent forwarding allows clients to use their SSH keys to authenticate to other servers without having to enter their passwords again.

Example values:

  • yes (default)
  • no

GatewayPorts

The GatewayPorts setting specifies whether remote hosts are allowed to connect to forwarded ports on the SSH server. By default, forwarded ports can only be accessed from the server itself, but enabling GatewayPorts allows remote hosts to connect to them as well. This can be useful for providing access to services running on the SSH server.

Example values:

  • yes (default)
  • no

Subsystem

The Subsystem setting specifies a subsystem to be executed when a specific command is requested by the client. This can be used to provide access to specific services or applications on the SSH server. For example, if the client requests the SFTP subsystem, the SSH server may execute the sftp-server command, passing the appropriate arguments to provide SFTP functionality.

It's worth noting that the Subsystem option should be used with caution, as it can potentially introduce security risks if not configured properly. Administrators should ensure that any custom commands used with the Subsystem option are secure and do not allow unauthorized access or privilege escalation.

Example values:

  • sftp /usr/lib/openssh/sftp-server (default)
  • sftp /usr/sbin/proftpd_sftp
  • backup /usr/local/bin/backup_service
  • scp /usr/bin/scp -t
  • git git-shell

TCPKeepAlive

The TCPKeepAlive setting specifies whether the SSH server should send TCP keep-alive messages to the client to prevent the connection from being closed by firewalls or routers.

Example values:

  • yes (default)
  • no

ClientAliveInterval

The ClientAliveInterval setting specifies the interval at which the SSH server sends a keep-alive message to the client. This can help keep connections open even if there is no activity for a prolonged period.

Example values:

  • 300 (5 minutes)
  • 900 (15 minutes)

ClientAliveCountMax

The ClientAliveCountMax setting specifies the maximum number of keep-alive messages that can be sent without receiving a response from the client. If this limit is reached, the server terminates the connection

Example values:

  • 3 (default)
  • 5
  • unlimited

The Banner setting specifies a message that is displayed to the client before authentication. This can be used to display a warning message or a legal notice.

Example values:

  • /etc/issue.net
  • /etc/banner.txt

AcceptEnv

The AcceptEnv setting specifies a list of environment variables that are allowed to be set by the client and passed to the SSH server. This can be useful for passing configuration settings or other information to the server.

Example values:

  • LANG
  • LC_*
  • MY_CUSTOM_VARIABLE

UseDNS

The UseDNS setting specifies whether the SSH server should perform reverse DNS lookups on the client's IP address. This can be useful for logging and monitoring purposes but can also slow down connection times if DNS is not configured correctly.

Example values:

  • yes (default)
  • no

Compression

The Compression setting specifies whether compression is enabled for SSH connections. Compression can reduce the amount of data transmitted over the network, which can be useful for slow or high-latency connections. However, it can also increase CPU usage on the server and client.

Example values:

  • yes (default)
  • no

LogLevel

The LogLevel setting specifies the level of detail to be logged by the SSH server. This can be useful for troubleshooting connection issues or identifying security threats.

Example values:

  • QUIET
  • FATAL
  • ERROR
  • INFO
  • VERBOSE
  • DEBUG

AllowUsers

The AllowUsers setting specifies a list of users who are allowed to log in to the SSH server. This can be used to restrict access to specific users or groups.

Example values:

  • user1
  • user2
  • *@example.com

DenyUsers

The DenyUsers setting specifies a list of users who are denied access to the SSH server. This can be used to block specific users or groups from accessing the server.

Example values:

  • baduser1
  • baduser2
  • *@badexample.com

AllowGroups

The AllowGroups setting specifies a list of groups whose members are allowed to log in to the SSH server. This can be used to restrict access to specific groups of users.

Example values:

  • sshusers
  • admins

DenyGroups

The DenyGroups setting specifies a list of groups whose members are denied access to the SSH server. This can be used to block specific groups of users from accessing the server.

Example values:

  • sshblacklist
  • hackers

Conclusion

The SSH daemon configuration file is a critical component of secure remote access. By properly configuring this file, system administrators can control various aspects of the SSH protocol, such as authentication methods, encryption, and access controls. Adhering to best practices, such as disabling root login and enforcing strong passwords, can greatly improve the security of remote access to a system.

However, it is important to note that SSH configuration is just one aspect of a comprehensive security strategy. Other security measures, such as firewalls, intrusion detection systems, and regular patching, are also necessary to maintain a secure environment.