Shulou(Shulou.com)06/02 Report--

This article introduces the knowledge of "how to configure SSH server security". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Use only the SSHv2 protocol

SSHv1 is a known insecure implementation of the SSH protocol, and to ensure the integrity of the system, the SSH service should be configured to accept only SSHv2 connections.

Configure the SSH service to accept only the SSHv2 protocol by uncommenting the configuration on the following line.

Protocol 2

Note: RedHat and CentOS use SSHv2 as the default configuration after version 7.4, but I still like to write this line to the configuration file.

Turn off or delay compression

SSH can use the gzip algorithm to compress data, which may affect the system if there are vulnerabilities in the compression software.

There has been a lot of discussion about whether compression needs to be enabled on fast connections, and it is generally believed that compression actually slows down processing, unless you use slow connections (modems, ISDN, etc.). If you must use the compression feature, use the delay feature to ensure that the user is authenticated before compression begins.

Turn off compression (recommended):

Compression no

To delay compression until after authentication, you need to modify it to:

Compression delayed

The "fast connection" and "slow connection" here do not quite understand. The original text is "fast connections" and "slow connection", which may refer to the transmission rate of the communication channel.

Limit the maximum number of authentication attempts

Limiting the maximum number of failed authentication is a good way to mitigate brute force attacks. Setting MaxAuthTries to a lower number (x) will force the session to be disconnected after the user has x failed attempts.

To limit the maximum number of authentication attempts, modify the configuration in sshd_config as follows:

MaxAuthTries 3

You can set this number as low as you like, but 3 is a good balance between security and convenience in my opinion.

You can lower this number as much as you like, but I think "3" is a more balanced setting between safety and convenience.

Disable root account login

If you allow root users to log in, you cannot associate actions with users, and forcing users to log in using user-specific accounts ensures accountability. In addition, this setting can further protect your root account from other types of attacks.

To prevent users from logging in using the root account, modify the configuration as follows:

PermitRootLogin no

This configuration is highly recommended.

Displays the date and time of the last login

This is usually the default setting in modern systems, but it is still important to check that it is configured correctly. By printing the date and time of the last login, users can be aware of unauthorized account login events, which will help to further investigate unrecognized visits.

To output the date and time of the last login, modify the configuration as follows:

PrintLastLog yes

It's a safe shortcut.

End an idle SSH session

Keeping the SSH session open indefinitely is not a good idea because users may leave their workstations, giving an unauthorized user a good opportunity to execute commands on an unattended workstation. The best way is to terminate an idle SSH session in a short period of time without giving others a chance.

The ClientAliveCountMax option and the ClientAliveInterval option work together, for example, to close an inactive session after 15 minutes (900 seconds), modify the configuration file as follows:

ClientAliveInterval 900ClientAliveCountMax 0

For more information about ClientAliveInterval:

Set the timeout interval (in seconds) after which if no data is received from the client, the sshd server sends a message requesting a response from the client through an encrypted channel. The default value is 0, which means that the operation will not be performed.

For more information about ClientAliveCountMax:

Sets the number of client-side drill-through messages (described above), and if the sending client-side drill-down message reaches this threshold, the sshd server disconnects the client, terminating the session.

Specify whitelist users

You can use the whitelist to specify authorized users to connect to the SSH server. Only those users in this list have the right to log in to SSH, while others can't. There are a lot of benefits in doing so.

If only "pfloyd", "rwaters" and "dgilmour" are allowed, modify the configuration file as follows:

AllowUsers pfloyd rwaters dgilmour

You can also use DenyUsers to disable certain users, such as modifying the configuration file:

DenyUsers root ncarter ajmclean hdorough

This setting is not always available, and if your environment can support this configuration, it will certainly improve security.

Disable empty password

Make sure that any SSH connection requires a non-empty password string (this does not affect the SSH key authentication login mode).

Modify the configuration file as follows:

PermitEmptyPasswords no

This is another simple but important configuration and is recommended for all non-special cases.

If you use password authentication, it is a wise choice to implement password complexity rules. These rules can be made by your organization, or try the following "best practices":

The password length is greater than x

The password contains at least x lowercase characters

The password contains at least x uppercase characters

The password contains at least x digits

The password contains at least x special characters

The password must not contain a user name (forward or reverse)

To learn more about setting password complexity, see "how to enforce password complexity in RedHat." although this article is aimed at RedHat, it can be run on any Linux system that uses the latest version of PAM (pluggable authentication module).

Disable password-less login based on trusted hosts

Rhosts files are a way to control trust relationships between systems. If one system trusts another, the system does not need a password to allow logins from trusted systems. This is an old configuration and should be explicitly disabled in the SSH configuration.

To ensure that SSH does not allow trusted hosts to connect, modify the configuration file as follows:

IgnoreRhosts yes

Rhosts files are rarely used, and it is recommended that you enable this configuration in most cases.

Disable access based on known hosts

The known_hosts file is used to identify the server, and when the user initiates a SSH connection, SSH compares the server fingerprint with the fingerprint stored in the known_hosts file to ensure that the user is connected to the correct system. This configuration works with the rhosts configuration to ensure that a password is required to connect to the remote host (by setting this option to ensure that each connection treats the remote host as an "untrusted" host).

To ignore known hosts during authentication, modify the configuration file as follows:

IgnoreUserKnownHosts yes

This configuration applies to most environments.

Disable host-based authentication

This feature is similar to trusted host-based authentication, but only for SSH-2. In my experience, this feature is rarely used and should be set to no.

To disable host-based authentication, modify the configuration file as follows:

HostBasedAuthentication no

This option is set to no by default, but I explicitly add it to the configuration file just to be on the safe side.

Disable X11Forwarding

X11Forwarding allows programs to be executed remotely through a SSH session with an explicit graphical interface on the client side. If there are no special requirements, they should be disabled.

To disable X11Forwarding, modify the configuration file as follows:

X11Forwarding no

X11Forwarding is rarely used, and I recommend disabling it on most systems.

Use unconventional port

By default, SSH listens on TCP port 22, which is often scanned by hackers and script boys to determine whether the target is running SSH. In addition, 2222 and 2121 are also commonly used listening ports. It is best not to use these ports, but to use unusual high-end ports, such as port 9222 in the example.

To set SSH snooping on unconventional ports, please modify the configuration file as follows

Port 9222

I don't usually modify the default ports behind the firewall, but this setting is necessary if your host is exposed to the Internet or other untrusted networks.

Note: don't forget to change the firewall rules to allow traffic to access your custom port.

Binds the service to the specified IP

By default, SSH listens for all IP addresses configured on the local machine, but you should specify that the SSH is bound to a specific IP, preferably in a private VLAN.

To specify the binding address, please modify the configuration file as follows

ListenAddress 10.0.0.5

This setting usually works with port binding.

Protect SSH key protect host private key

You should protect the host private key from unauthorized access. If the private key is compromised, the host may be spoofed, so all private key files should be set to allow access only to root users (corresponding permission is 0600).

Use the ls command to list all private key files under the / etc/ssh/ folder:

Ls-l / etc/ssh/*key

Use the chmod command to set private key file permissions:

Chmod 0600 / etc/ssh/*key

In most cases, the private key file is stored in the / etc/ssh/ folder, but it may also be stored in another directory, and the storage location set in the configuration file can be retrieved with the following command:

Grep-I hostkey / etc/ssh/sshd_config protects the host public key

Although the public key is not as important as the private key, you should protect it, because if the public key is tampered with, it may cause the SSH service to fail or deny service, so you need to configure permission to only allow the root account to modify it (corresponding permission is 0644).

Use the ls command to list all public key files in the / etc/ssh/ directory:

Ls-l / etc/ssh/*pub

Use the chmod command to modify public key file permissions:

Chmod 0644 / etc/ssh/*pub

Typically, the public key and the private key are stored in the same directory, or use the method in the previous section to find the storage path.

Check the user-specific profile

Users may inadvertently make their home directory or some other files globally writable (such as 777 permissions), in which case other users will have the right to modify user-specific configurations and log in to the server as other users. You can check the configuration of the home directory by using the StrictModes option.

StrictModes sets whether ssh checks the permissions and ownership of the user's home directory and rhosts file before receiving login. StrictModes is yes must ensure that the owner of the folder where the public key is stored is the same as the login user name.

To ensure that strict mode is enabled, modify the configuration file as follows:

StrictModes yes

This method is recommended, especially for systems with a large number of users.

Prevent privilege escalation

SSH separates permissions by creating an unprivileged child process to receive incoming connections. After the user is authenticated, SSH creates another process with the user's privileges.

In the systems I know, this option is turned on by default, but to be on the safe side, it is recommended that you manually modify the configuration file to explicitly specify the configuration:

UsePrivilegeSeparation sandbox

Additional restrictions can be added with sandbox.

Use the key for authentication

This feature is not necessarily available on all systems, but there are many advantages to using SSH key authentication. Key authentication is much more powerful than any password that humans can easily remember, and it also provides password-free authentication, making it easier to use.

To enable key authentication, modify the configuration file as follows:

PubkeyAuthentication yes

This option defaults to yes on most systems.

For more information about SSH key authentication, refer to How to Setup SSH Key Authentication.

Disable authentication methods that are not used

Linux administrators know that good security practice is to stop and delete all unused services, and you should also disable any other authentication methods that are not used in SSH.

Here, I'll show you how to disable all authentication, but be careful: don't disable them all, keep what you need.

Disable GSSAPI authentication

Through the Common Security Services Application programming Interface (GSSAPI), you can use advanced configuration and other authentication methods (except passwords and key authentication). If you do not use this feature, modify the configuration file as follows:

GSSAPIAuthentication no disables Kerberos authentication

Similarly, disable if not needed:

KerberosAuthentication no disables password authentication

If you configure a more advanced authentication method, you can disable password authentication:

PasswordAuthentication no disables key authentication

If you use other authentication methods, you can disable key authentication. Compared with other methods, the use of key authentication is a less risky approach. To disable it, modify the configuration file as follows:

PubkeyAuthentication no uses passwords that conform to the FIPS 140-2 standard

Use FIPS 140-2 compliant specifications to avoid using weak encryption algorithms, please modify the configuration file as follows:

Ciphers aes128-ctr,aes192-ctr,aes256-ctr

This setting limits the encryption available for SSH, so you need to verify the compatibility of any older clients, scripts, or applications that may be used before applying.

FIPS 1402 is a security requirement standard for cryptographic modules issued by the National Standards and Technology Commission of the United States. It is widely used as a federal information processing standard in government agencies.

Use MAC that complies with FIPS 1402 standard

As in the previous section, use specifications that conform to FIPS 140-2 and avoid using weakly encrypted hash algorithms:

MACs hmac-sha2-256 Hmacshasha2-512 configure host firewall to filter incoming SSH connections

Checking incoming SSH connections is also a good way to protect SSH by allowing only specific IP or subnets to connect to the system. The following shows how to configure a firewall through iptables, firewalld, and Uncomplicated Firewall (UFW).

Use iptables to filter SSH connections

Allow specific IP connections:

Iptables-I INPUT-p tcp-s-dport 22-j ACCEPT

Allow specific subnets:

Iptables-I INPUT-p tcp-s-dport 22-j ACCEPT

For more information about how to use iptables, please refer to The Basics of IPTables.

Filter SSH connections through Firewalld

Allow a specific IP to connect to the SSH:

Firewall-cmd-permanent-zone=public-add-rich-rule=' rule family= "ipv4" source address= "port protocol=" tcp "port=" 22 "accept'

Allow specific subnets:

Firewall-cmd-permanent-zone=public-add-rich-rule=' rule family= "ipv4" source address= "port protocol=" tcp "port=" 22 "accept' use UFW to filter SSH connections

Allow a specific IP to connect to the SSH:

Sudo ufw allow from to any port 22

Allow specific subnets:

Sudo ufw allow from to any port 22 sets a Banner

In my experience, this does more harm than good, although modifying Banner (connection prompt message) can stop some script boys, but a few experienced birds may see it as a provocation, so if you do want to add Banner, consider the tone of the message.

To enable custom Banner, modify the configuration file as follows:

Banner / etc/issue

Edit the / etc/issue file to add prompts after connecting to the SSH.

This is the end of "how to configure SSH server security". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.