15 Best Steps to Simplify Your SSH configuration in Linux

In this article, I will take you through the ssh config file example in Linux. SSH (Secure Shell) is an essential protocol in Linux and Unix-like systems used for securely accessing remote machines over an unsecured network. It provides a secure channel over an unsecured network by using a client-server architecture, where the ssh client connects to the sshd server. SSH is widely used for a range of activities, from remote system maintenance to transferring files securely. Configuring SSH in Linux can sometimes be challenging so here we are going to look into 15 best steps to simplify the configuration in Linux.

 

Sponsored

SSH Configuration

The SSH configuration in Linux is governed by two main files:-

a) /etc/ssh/sshd_config

• This is the configuration file for the SSH daemon (sshd), which runs on the server.
• It controls the server-side aspects of SSH, like setting the default SSH port (22), specifying which users or groups are allowed or denied SSH access, configuring key-based authentication, setting login banners, and more.
• Modifications to sshd_config require restarting the SSH service to take effect.

b) ~/.ssh/config (Client Configuration)

• This file is used by the SSH client and allows users to create SSH client-side configurations, including specifying aliases for hostnames, defining different usernames for different hosts, and setting other preferences for individual SSH connections.
• This file does not exist by default and can be created by the user. It’s especially useful for users who SSH into multiple servers with different settings.

 

15 Best Steps to Simplify Your SSH configuration in Linux

Also Read: How to Install bmon (Bandwidth Monitoring Tool) on Ubuntu 20.04

Step 1: Check permission of /etc/ssh/sshd_config File

The /etc/ssh/sshd_config file contains sensitive configuration details of the SSH server, including authentication methods, allowed users, port numbers, and other settings that dictate how SSH operates on the server. If unauthorized users can modify this file, they could alter the SSH server’s behavior to bypass security controls, grant themselves access, or create other security vulnerabilities. Run below command and verify uid and gid are both 0/root :-

[root@localhost ~]# stat /etc/ssh/sshd_config
File: ‘/etc/ssh/sshd_config’
Size: 3907 Blocks: 8 IO Block: 4096 regular file
Device: fd00h/64768d Inode: 219047 Links: 1
Access: (0600/-rw-------) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2020-06-12 17:26:00.768925247 -0400
Modify: 2019-08-08 21:40:39.000000000 -0400
Change: 2020-04-23 16:10:02.267286283 -0400
.......................

 

 

Step 2: Set SSH Config Protocol to 2

SSH protocol 2 is more secure and robust than the older protocol 1, which has several vulnerabilities. The SSH protocol 1 is outdated and has known security issues. It’s generally recommended to use protocol 2 exclusively. Modern SSH clients and servers support protocol 2, so this change should not impact compatibility for most users. SSH protocol 2 provides several security enhancements, including stronger encryption algorithms and improved authentication methods. You can check the current protocol set by using grep "^Protocol" /etc/ssh/sshd_config command as shown below.

[root@localhost ~]# grep "^Protocol" /etc/ssh/sshd_config

If SSH Protocol 2 is not set then edit the /etc/ssh/sshd_config file to set the parameter as follows:-

[root@localhost ~]# vi /etc/ssh/sshd_config
....................
Protocol 2
.....................

 

 

Step 3: Ensure SSH LogLevel is set to INFO

The LogLevel directive specifies the verbosity level of the messages logged by the SSH daemon, which can be crucial for auditing and troubleshooting. Setting its value to INFO ensures that detailed informational messages will be logged, which is helpful for understanding the activities of the SSH server without being overly verbose. By default, SSH logs to the syslog facility, and the logs can typically be found in /var/log/auth.log or /var/log/secure, depending on your system’s configuration.

It is also worth mentioning that the LogLevel can impact the size of log files. While INFO is generally a good balance between verbosity and brevity, in highly active systems, even this level can generate substantial logs over time. The INFO level is usually sufficient for security auditing and general troubleshooting. It provides information about user logins, logouts, and other key SSH activities. To check current LogLevel setting, run below command.

[root@localhost ~]# grep "^LogLevel" /etc/ssh/sshd_config

You can set LogLevel parameter in /etc/ssh/sshd_config file as shown below.

[root@localhost ~]# vi /etc/ssh/sshd_config
..................................
LogLevel INFO
..................................

 

 

Step 4: Ensure SSH X11 forwarding is disabled

X11 forwarding in SSH is a powerful feature that enables running remote graphical applications with their display on your local machine. It’s essential to configure it correctly and be mindful of the security implications. This feature is particularly useful for users who need to run specific GUI applications on a server while interacting with them from their personal workstation.

X11 forwarding can introduce security risks, as it opens a channel for X11 data to be transmitted. So it is mostly recommended to keep it disable until there is an absolute requirement to enable this setting. To check current setting, run below command:-

[root@localhost ~]# grep "^X11Forwarding" /etc/ssh/sshd_config
X11Forwarding yes

To change the setting, edit /etc/ssh/sshd_config file and update as follows:-

[root@localhost ~]# vi /etc/ssh/sshd_config
..............................
X11Forwarding no
..............................

 

 

Step 5: Ensure SSH MaxAuthTries is set to 4 or less

MaxAuthTries in sshd_config is a crucial configuration for securing the SSH server against brute-force login attempts. This directive specifies the maximum number of authentication attempts that are allowed per connection. Essentially, it sets a limit on how many times a user can try to log in during a single SSH session before being disconnected.

Setting the MaxAuthTries directive in the sshd_config file to 4 or less is a security measure that limits the number of authentication attempts a client can make during a single SSH session. This setting helps to mitigate brute-force password attacks by reducing the number of guesses an attacker can make. To check the current setting, run below command:-

[root@localhost ~]# grep "^MaxAuthTries" /etc/ssh/sshd_config

To set MaxAuthTries to 4 or less, edit the /etc/ssh/sshd_config file and set it like below:-

[root@localhost ~]# vi /etc/ssh/sshd_config
...........................
MaxAuthTries 4
...........................

 

 

Step 6: Enable IgnoreRhosts in ssh config file

IgnoreRhosts is a directive in the sshd_config file for SSH (Secure Shell) on Linux and Unix-like systems. It’s used to enhance security by controlling how SSH handles .rhosts and .shosts files. These files are part of the Rhosts or RhostsRSA authentication methods, which are generally considered insecure and outdated.

Setting IgnoreRhosts to yes in sshd_config is a good security practice. It prevents SSH from using .rhosts and .shosts files for authentication, thus mitigating the risks associated with these older, less secure authentication methods. Always pair this with other SSH hardening practices for maximum security. To check current settings, run grep "^IgnoreRhosts" /etc/ssh/sshd_config command as shown below.

[root@localhost ~]# grep "^IgnoreRhosts" /etc/ssh/sshd_config

Edit the /etc/ssh/sshd_config file to set the parameter as follows:-

[root@localhost ~]# vi /etc/ssh/sshd_config
............................
IgnoreRhosts yes
............................

 

 

Step 7: Ensure SSH HostbasedAuthentication is disabled

HostbasedAuthentication in sshd_config is an SSH configuration option that allows users to log in to an SSH server from a client machine without providing their individual credentials, based on the host they are connecting from. This method relies on the trust relationship between the host machines, and it is similar to but distinct from public key authentication.

To enable Enable HostbasedAuthentication, set it to yes. You can check current configuration by running grep "^HostbasedAuthentication" /etc/ssh/sshd_config command as shown below.

[root@localhost ~]# grep "^HostbasedAuthentication" /etc/ssh/sshd_config

Edit the /etc/ssh/sshd_config file to set the parameter as follows:-

[root@localhost ~]# vi /etc/ssh/sshd_config
................................
HostbasedAuthentication no
................................

 

 

Step 8: Disable root login in ssh config file

The PermitRootLogin directive in the sshd_config file controls whether the root user is allowed to log in using SSH. This is an important security setting in SSH server configuration. There are three types of configuration settings that can be done for PermitRootLogin directive:-

• Setting PermitRootLogin to no prevents the root user from logging in via SSH.
• Setting PermitRootLogin to yes allows the root user to log in using a password. but make a note that this is not recommended due to security risks.
• Setting PermitRootLogin to without-password or prohibit-password allows root login only using SSH key-based authentication, which is more secure than password-based authentication.

You can check the current setting by running grep "^PermitRootLogin" /etc/ssh/sshd_config command as shown below.

[root@localhost ~]# grep "^PermitRootLogin" /etc/ssh/sshd_config

Edit the /etc/ssh/sshd_config file to set the parameter as follows:-

[root@localhost ~]# vi /etc/ssh/sshd_config
...............................
PermitRootLogin no
...............................

 

 

Step 9: Disable PermitEmptyPasswords in ssh config file

The PermitEmptyPasswords is a configuration option in the sshd_config file for the SSH (Secure Shell) daemon. This option controls whether the SSH server allows user logins with empty passwords. Permitting empty passwords can be a significant security risk, especially for accounts with remote SSH access. It makes unauthorized access much easier.

By default, PermitEmptyPasswords is set to no in most SSH configurations, which is the recommended setting for security. Setting PermitEmptyPasswords to yes might be considered in very controlled environments, such as an automated test system in a secure, isolated network, but it’s generally advised against. To check current setting, run below command:-

[root@localhost ~]# grep "^PermitEmptyPasswords" /etc/ssh/sshd_config

Edit the /etc/ssh/sshd_config file to set the parameter as follows:

[root@localhost ~]# vi /etc/ssh/sshd_config
.................................
PermitEmptyPasswords no
.................................

 

 

Step 10: Disable PermitUserEnvironment in ssh config file

The PermitUserEnvironment option controls whether the SSH server allows users to set environment variables for their SSH sessions through separate user-controlled files. Allowing user-controlled environment settings can be a security risk, as it might be used to bypass access restrictions in some configurations or lead to other unintended security consequences. By default, PermitUserEnvironment is set to no in most SSH server configurations for security reasons. To check current setting, run below command:-

[root@localhost ~]# grep PermitUserEnvironment /etc/ssh/sshd_config
#PermitUserEnvironment no

To change the value, you can edit /etc/ssh/sshd_config file as follows:

[root@localhost ~]# vi /etc/ssh/sshd_config
...................................
PermitUserEnvironment no
...................................

 

 

Step 11: Use only approved MAC algorithms in ssh config file

MAC algorithms are used to ensure the integrity and authenticity of the data in SSH connections. Modifying the SSH configuration to use only approved Message Authentication Code (MAC) algorithms enhances the security of SSH communications.

Specifying a set of approved MAC algorithms in the SSH configuration is a crucial aspect of securing SSH communications. By enforcing the use of strong and secure MACs, you can significantly enhance the integrity and authenticity of the data transferred over SSH. Regular updates and testing are important to maintain the effectiveness of these security measures. Check the current setting by running below command:-

[root@localhost ~]# grep "MACs" /etc/ssh/sshd_config

You can also edit /etc/ssh/sshd_config file to set the parameter in accordance with site policy. The following includes all supported and accepted MACs:-

[root@localhost ~]# vi /etc/ssh/sshd_config
..............................................
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com

 

 

Step 12: Ensure SSH Idle Timeout Interval is configured

Configuring an SSH Idle Timeout Interval is an important security measure. It automatically disconnects an SSH session after a certain period of inactivity, reducing the risk of unauthorized access to an idle session. This is particularly important for environments where users might forget to log out from their SSH sessions.

To configure the idle timeout interval, you need to set two directives in the SSH daemon configuration file (sshd_config): ClientAliveInterval and ClientAliveCountMax.

• Set ClientAliveInterval: This directive specifies the time in seconds that the server will wait before sending a null packet to the client to keep the connection alive. Set it to a desired interval (in seconds). For example, 300 means the SSH server will send a keep-alive message every 300 seconds if it detects no activity.
• Set ClientAliveCountMax: This directive defines the maximum number of keep-alive messages the server will send without receiving any response from the client. After this, the session is terminated. For example, if we set ClientAliveCountMax to 3 then it means server will terminate the session if no response is received after 3 keep-alive messages. With ClientAliveInterval set to 300, this results in a total idle time of 15 minutes (300 seconds * 3) before disconnecting.

To check current setting, run below command:-

[root@localhost ~]# grep "^ClientAliveInterval" /etc/ssh/sshd_config
[root@localhost ~]# grep "^ClientAliveCountMax" /etc/ssh/sshd_config

To edit the value in /etc/ssh/sshd_config file, open it with vi or nano editor and change it accordingly as shown below:-

[root@localhost ~]# vi /etc/ssh/sshd_config
...............................
ClientAliveInterval 300
ClientAliveCountMax 0
...............................

 

 

Step 13: Ensure SSH LoginGraceTime is set to one minute or less

The LoginGraceTime setting specifies the time allowed for successful login to the SSH server. If the user fails to authenticate within this timeframe, the server disconnects the session. Be aware that setting a short LoginGraceTime may affect users with slow connections or those who take longer to authenticate. They might find their connections being dropped more frequently. A shorter LoginGraceTime can enhance security by limiting the time available for unauthorized login attempts. It’s a part of hardening the SSH service.

Setting LoginGraceTime to one minute or less is a good practice for enhancing the security of your SSH server. It helps to mitigate risks associated with prolonged unauthenticated connections. To check the current value and verify that output LoginGraceTime is between 1 and 60, use below command.

[root@localhost ~]# grep "^LoginGraceTime" /etc/ssh/sshd_config

In case it is not set, edit /etc/ssh/sshd_config file to set the parameter as follows:-

[root@localhost ~]# vi /etc/ssh/sshd_config
..........................
LoginGraceTime 60
..........................

 

 

Step 14: Ensure SSH access is limited

Limiting SSH access is an important security measure for any server. There are several options available to limit which users and group can access the system via SSH. It is recommended that at least one of the following options be leveraged.

• AllowUsers: It is a directive in the sshd_config file, which is the configuration file for the SSH (Secure Shell) daemon. The AllowUsers directive specifies which users are allowed to log in to the SSH server. It is a security measure used to restrict SSH access to a specified list of user accounts. It provides a way to create an allowlist (or whitelist) of user names. Only the users specified in this list are permitted to log in to the server via SSH.
• AllowGroups: The AllowGroups directive is used to specify which user groups are allowed to establish an SSH connection to the server. It’s a part of access control mechanisms in SSH that helps in enhancing security by limiting SSH access to members of certain groups.
• DenyUsers: DenyUsers is used to explicitly deny SSH access to specified user accounts. It’s a part of the access control mechanism in SSH and serves as a way to enhance security by preventing certain users from establishing SSH connections to your server. The DenyUsers directive blocks SSH access for the listed user accounts. It’s useful in situations where you want to prevent specific users from logging in via SSH, regardless of their authentication method.
• DenyGroups: DenyGroups in sshd_config is a powerful directive for restricting SSH access for users based on their group membership. It provides administrators with an additional layer of control over who can access the SSH server, enhancing the overall security posture of the system. This directive is used to block SSH access for users who are members of specified groups.

You can check current settings of all above directives using below command:-

[root@localhost ~]# grep "^AllowUsers" /etc/ssh/sshd_config
[root@localhost ~]# grep "^AllowGroups" /etc/ssh/sshd_config
[root@localhost ~]# grep "^DenyUsers" /etc/ssh/sshd_config
[root@localhost ~]# grep "^DenyGroups" /etc/ssh/sshd_config

You can set all the parameters in /etc/ssh/sshd_config file as shown below.

[root@localhost ~]# vi /etc/ssh/sshd_config
.................................
AllowUsers 
AllowGroups 
DenyUsers 
DenyGroups 
..................................

 

 

Step 15: Ensure SSH warning banner is configured

The Banner directive in the sshd_config file is used to specify a text banner that will be displayed to users before they authenticate when connecting to the SSH server. This banner is often used for legal or informational purposes, such as displaying a warning message or terms of use. It is displayed before authentication, so it’s one of the first things a user sees when connecting to the SSH server.

While a banner can be used for legal warnings, it should not disclose sensitive information about the system, as it is visible to anyone attempting to connect. To check the current path of your banner file, run grep "^Banner" /etc/ssh/sshd_config command as shown below.

[root@localhost ~]# grep "^Banner" /etc/ssh/sshd_config

To set a new path, open /etc/ssh/sshd_config file using vi or nano editor and set the Banner path like below.

[root@localhost ~]# vi /etc/ssh/sshd_config
..........................
Banner /etc/issue.net
..........................