Introduction
SH is the main way to connect to remote Linux and Unix-like servers using the command line. It lets you securely run commands, interact with the system, and even send other types of data through it.
To connect, use ssh username@server-ip-address or hostname.
For example:
# ssh root@192.168.3.154
However, your SSH daemon can have many settings you can adjust to improve security, manage user access, and more. We'll review some of these options to give you better control over your SSH access.
We'll demonstrate these concepts on an Ubuntu 20.04 VPS, but the steps should be similar for any modern Linux distribution.
Relationship of Configuration Files
The SSH server reads several configuration files. The sshd_config file is the main one, and it specifies where to find the host key files (which are required) and the authorized_keys files for users. It may also refer to other files as needed.
Understanding the SSHD Configuration File
The main settings for the SSH server are found in the /etc/ssh/sshd_config file. This is different from the ssh_config file, which is for client settings.
To open the file with admin rights, use:
# nano /etc/ssh/sshd_config
Depending on your system, you'll see a file with many options and probably a lot of comments. Most systems have good default settings, but there's always room to improve and customize.
Let’s review some of the options already set in our Ubuntu 20.04 file:
Ports and Protocols
Port 22: This is the port where the SSH server listens for connections. By default, it's set to port 22, which most clients and servers use. Changing it to a different port can help reduce attackers' random login attempts.
Protocol 2: SSH has two versions of protocols. It's best to keep using Protocol 2 unless you need to support older clients that only work with Protocol 1.
Keys and Separation
HostKey /etc/ssh/ssh_host…: These lines specify the server's host keys, which are used to identify the server to clients. If a client has connected to the server before, it uses these keys to verify the new connection.
UsePrivilegeSeparation yes: This setting allows SSH to create separate processes with only the permissions needed for their tasks. It's a security feature that helps protect the system in case of an exploit.
KeyRegenerationInterval and ServerKeyBits: These settings are related to the server key for SSH protocol 1. You don't need to worry about them if you require connections to use protocol 2.
Logging and Restrictions
SyslogFacility and LogLevel: These settings control how SSH activity is logged. The first sets where the logs go, and the second decides how detailed the logs should be.
LoginGraceTime 120: This option sets the time in seconds that the server waits before disconnecting a client if there's no successful login.
PermitRootLogin yes: This allows or blocks SSH access using the root account. Since the root account has full control of the server, it's a common target for attackers. It's recommended to set this to "no" after setting up a regular user with sudo privileges.
StrictModes yes: This tells SSH to ignore user configuration files if they don't have the correct permissions. For example, if a user's files are accessible to everyone, SSH will block access until this is fixed to avoid security risks.
IgnoreRhosts and RhostsRSAAuthentication: These settings determine whether older rhost authentication methods are allowed. These only apply to the outdated SSH protocol 1, not protocol 2.
HostbasedAuthentication no: This option is the protocol 2 version of the above, allowing authentication based on the client's host. It's generally not safe outside isolated environments because the source information can be faked. You can set up host info in the /etc/ssh/shosts.equiv or /etc/hosts.equiv files, but this is beyond the scope of this guide.
PermitEmptyPasswords no: This blocks SSH access for accounts without a password when password authentication is used. Allowing this would be a major security risk, so it's best to keep it set to "no."
ChallengeResponseAuthentication: This setting enables or disables a challenge-response authentication method, which can be configured through PAM (Pluggable Authentication Modules). This is outside the scope of this guide.
Display
X11Forwarding yes: This allows you to run graphical applications on the server and interact with them on your client machine. For this to work, the client needs an X windowing system, which is built into desktop Linux and can be installed on OS X.
X11DisplayOffset 10: This sets a display number offset for X11 forwarding in SSH. It helps prevent conflicts between the SSH-generated X11 windows and the existing X server on the client.
PrintMotd no: This tells the SSH server not to show the "message of the day" file when you log in. Sometimes, the shell will still display it, so you may need to adjust your shell settings as well.
PrintLastLog yes: This option tells the SSH server to show you the last time you logged in.
Connection and Environment
TCPKeepAlive yes: This setting determines if the server sends TCP keepalive messages to the client. These messages help the server detect problems and disconnects the client if needed. If disabled, connections won't drop during brief network issues, which can be good, but it might also leave resources locked up if users get disconnected.
AcceptEnv LANG LC*: This option allows the server to accept certain environment variables from the client. In this case, it accepts language settings, ensuring the shell session displays correctly for the client.
Subsystem sftp /usr/lib/openssh/sftp-server: This sets up external systems to work with SSH. Here, it specifies an SFTP server and the path to run it.
UsePAM yes: This enables PAM (Pluggable Authentication Modules) to help with user authentication.
These are the default enabled options on our Ubuntu 20.04 machine. Next, we’ll discuss other settings you might want to adjust.
Other SSHD Options
You can configure many other settings for the SSH server. Some might be helpful right away, while others are only useful in certain situations. We won't cover all of them here, but we'll discuss some of the more useful ones.
User and Group Filtering
Some options let you control which users can log in through SSH. These options are mutually exclusive, meaning others are automatically denied if you allow certain users or groups.
AllowGroups: This option lets you specify group names on the server. Only users in these groups can log in, creating a whitelist of groups with access.
AllowUsers: This is similar to the above but for individual users. Only users on this list can log in, acting as a whitelist for specific users.
DenyGroups: This sets a blacklist of groups that are not allowed to log in. Users in these groups are blocked from access.
DenyUsers: This is a blacklist for individual users, specifying who is not allowed to log in through SSH.
Additionally, there are some other restrictive options you can use alongside the above:
Match: This option gives more detailed control, allowing you to apply different settings when specific users or groups connect. We’ll cover this in more detail later.
RevokedKeys: This option lets you list revoked public keys, which prevents them from being used to log into the system.
Miscellaneous Options
There are several settings to control which network traffic the SSH server handles:
AddressFamily: This option determines which types of addresses the server will accept. By default, it accepts any address, but you can set it to “inet” for IPv4 or “inet6” for IPv6.
ListenAddress: This option lets you specify a particular address and port for the SSH server to listen to. By default, it listens on all addresses for the machine.
Other settings include those for certificate-based authentication, limiting connections with options like ClientAliveCountMax and ClientAliveInterval, and ChrootDirectory, which restricts a logged-in user to a specific, pre-configured environment.
Restricting User Logins
We’ve talked about tools to limit access for users and groups. Here’s more detail:
To specify which users can log in, use:
AllowUsers nick peter craig
You can list multiple users separated by spaces.
You can also use wildcards and exclusions. For example, to allow everyone except “shawn” to log in, you could use:
AllowUsers * !shawn
However, using DenyUsers might be clearer:
DenyUsers shawn
You can use ? to match exactly one character. For example:
AllowUsers ?im
This allows logins from users like “tim,” “jim,” or “vim.”
You can also restrict logins by specifying the client’s hostname:
AllowUsers nick@demovpstest.com noel
This allows “noel” to log in from anywhere but limits “nick” to log in only from “demovpstest.com.”
For more specific access control, you can use TCP wrappers configured in /etc/hosts.allow and /etc/hosts.deny. For example, to allow SSH access only from demovpstest.com:
Add to /etc/hosts.allow:
sshd: .demovpstest.com
And to /etc/hosts.deny:
sshd: ALL
This setup allows logins only from example.com and its subdomains.
Using Match Options to Add Exceptions
Using " match " options, you can make your SSH settings more specific. These options apply only when certain criteria are met.
To use a match, start with Match and define criteria with key-value pairs. The keys you can use are “User,” “Group,” “Host,” and “Address.” You can separate criteria with spaces and use commas for multiple patterns (e.g., user1,user2). Wildcards and negation can also be used:
Match User !nick,!peter Group sshusers Host *.demovpstest.com
This line applies the settings only if the user is not nick or peter, is in the sshusers group, and is connecting from demovpstest.com or a subdomain.
For “Address,” you can use CIDR notation.
Options following a Match line only apply under the specified conditions until the end of the file or the next Match line. It’s a good idea to place default settings at the top of the file and exceptions at the bottom.
Indented lines under a Match block show that those settings apply only to that match.
Match User! inick,!peter Group sshusers Host *.demovpstest.com
AuthorizedKeysFile /sshusers/keys/%u
PasswordAuthentication yes
X11Forwarding
X11DisplayOffset 15
To see all options available for match specifications, check the sshd_config manual:
# man sshd_config
Look for the “Match” section for a complete list of options.
Conclusion
You can change many settings on the SSH server that will impact how users log in and their experience. It's important to test these changes carefully before applying them widely to avoid errors and ensure that the restrictions affect only the intended users.
Knowing your /etc/ssh/sshd_config file is a great way to learn how to manage server access carefully. This is an important skill for any Linux system administrator.