Table of Contents
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.
The SSH configuration in Linux is governed by two main files:-
- 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
Step 1: Check permission of /etc/ssh/sshd_config File
/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
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/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.
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
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
.shosts files. These files are part of the
RhostsRSA authentication methods, which are generally considered insecure and outdated.
sshd_config is a good security practice. It prevents SSH from using
.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
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
noprevents the root user from logging in via SSH.
yesallows the root user to log in using a password. but make a note that this is not recommended due to security risks.
prohibit-passwordallows 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
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.
PermitEmptyPasswords is set to
no in most SSH configurations, which is the recommended setting for security. Setting
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
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 email@example.com,firstname.lastname@example.org,email@example.com,hmac-sha2-512,hmac-sha2-256,firstname.lastname@example.org
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: 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,
300means the SSH server will send a keep-alive message every
300 secondsif it detects no activity.
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
3then it means server will terminate the session if no response is received after 3 keep-alive messages. With
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
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
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
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_configfile, which is the configuration file for the SSH (Secure Shell) daemon. The
AllowUsersdirective 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
DenyUsersdirective 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 <userlist> AllowGroups <grouplist> DenyUsers <userlist> DenyGroups <grouplist> ..................................
Step 15: Ensure SSH warning banner is configured
The Banner directive in the
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
nano editor and set the Banner path like below.
[root@localhost ~]# vi /etc/ssh/sshd_config .......................... Banner /etc/issue.net ..........................