1.5. Making OpenSSH more secure
Harden your system security by modifying OpenSSH configurations, such as implementing stronger keys and restricting user access. This helps protect your server against various attacks.
Note that changes in the /etc/ssh/sshd_config OpenSSH server configuration file require reloading the sshd daemon to take effect:
# systemctl reload sshd
The majority of security hardening configuration changes reduce compatibility with clients that do not support up-to-date algorithms or cipher suites.
- Disabling insecure connection protocols
- To make SSH truly effective, prevent the use of insecure connection protocols that are replaced by the OpenSSH suite. Otherwise, a user’s password might be protected using SSH for one session only to be captured later when logging in using Telnet.
- Disabling password-based authentication
- Disabling passwords for authentication and allowing only key pairs reduces the attack surface. See the Setting key-based authentication as the only method on an OpenSSH server section for more information.
- Stronger key types
Although the
ssh-keygencommand generates a pair of RSA keys by default, you can instruct it to generate Elliptic Curve Digital Signature Algorithm (ECDSA) or Edwards-Curve 25519 (Ed25519) keys by using the-toption. The ECDSA offers better performance than RSA at the equivalent symmetric key strength. It also generates shorter keys. The Ed25519 public-key algorithm is an implementation of twisted Edwards curves that is more secure and also faster than RSA, DSA, and ECDSA.OpenSSH creates RSA, ECDSA, and Ed25519 server host keys automatically if they are missing. To configure the host key creation in RHEL, use the
sshd-keygen@.serviceinstantiated service. For example, to disable the automatic creation of the RSA key type:# systemctl mask sshd-keygen@rsa.service # rm -f /etc/ssh/ssh_host_rsa_key* # systemctl restart sshd注意In images with the
cloud-initmethod enabled, thessh-keygenunits are automatically disabled. This is because thessh-keygen templateservice can interfere with thecloud-inittool and cause problems with host key generation. To prevent these problems theetc/systemd/system/sshd-keygen@.service.d/disable-sshd-keygen-if-cloud-init-active.confdrop-in configuration file disables thessh-keygenunits ifcloud-initis running.To allow only a particular key type for SSH connections, remove a comment out at the beginning of the relevant line in
/etc/ssh/sshd_config, and reload thesshdservice. For example, to allow only Ed25519 host keys, the corresponding lines must be as follows:# HostKey /etc/ssh/ssh_host_rsa_key # HostKey /etc/ssh/ssh_host_ecdsa_key HostKey /etc/ssh/ssh_host_ed25519_key重要The Ed25519 algorithm is not FIPS-140-compliant, and OpenSSH does not work with Ed25519 keys in FIPS mode.
- Non-default port
By default, the
sshddaemon listens on TCP port 22. Changing the port reduces the exposure of the system to attacks based on automated network scanning on the default port and therefore increases security through obscurity. You can specify the port by using thePortdirective in the/etc/ssh/sshd_configconfiguration file.You also have to update the default SELinux policy to allow the use of a non-default port. To do so, use the
semanagetool from thepolicycoreutils-python-utilspackage:# semanage port -a -t ssh_port_t -p tcp <port_number>Furthermore, update
firewalldconfiguration:# firewall-cmd --add-port <port_number>/tcp # firewall-cmd --remove-port=22/tcp # firewall-cmd --runtime-to-permanentIn the previous commands, replace
<port_number>with the new port number specified using thePortdirective.- Root login
PermitRootLoginis set toprohibit-passwordby default. This enforces the use of key-based authentication instead of the use of passwords for logging in as root and reduces risks by preventing brute-force attacks.警告Enabling logging in as the root user is not a secure practice because the administrator cannot audit which users run which privileged commands. For using administrative commands, log in and use
sudoinstead.- Using the X Security extension
The X server in Red Hat Enterprise Linux clients does not provide the X Security extension. Therefore, clients cannot request another security layer when connecting to untrusted SSH servers with X11 forwarding. Most applications are not able to run with this extension enabled anyway.
By default, the
ForwardX11Trustedoption in the/etc/ssh/ssh_config.d/50-redhat.conffile is set toyes, and there is no difference between thessh -X remote_machine(untrusted host) andssh -Y remote_machine(trusted host) command.If your scenario does not require the X11 forwarding feature at all, set the
X11Forwardingdirective in the/etc/ssh/sshd_configconfiguration file tono.- Restricting SSH access to specific users, groups, or IP ranges
The
AllowUsersandAllowGroupsdirectives in the/etc/ssh/sshd_configconfiguration file server enable you to permit only certain users, domains, or groups to connect to your OpenSSH server. You can combineAllowUsersandAllowGroupsto restrict access more precisely, for example:AllowUsers *@192.168.1.* *@10.0.0.* !*@192.168.1.2 AllowGroups example-groupThis configuration allows only connections if all of the following conditions meet:
- The connection’s source IP is within the 192.168.1.0/24 or 10.0.0.0/24 subnet.
- The source IP is not 192.168.1.2.
- The user is a member of the example-group group.
The OpenSSH server permits only connections that pass all Allow and Deny directives in
/etc/ssh/sshd_config. For example, if theAllowUsersdirective lists a user that is not part of a group listed in theAllowGroupsdirective, then the user cannot log in.Note that using allowlists (directives starting with Allow) is more secure than using blocklists (options starting with Deny) because allowlists block also new unauthorized users or groups.
- Changing system-wide cryptographic policies
OpenSSH uses RHEL system-wide cryptographic policies, and the default system-wide cryptographic policy level offers secure settings for current threat models. To make your cryptographic settings more strict, change the current policy level:
# update-crypto-policies --set FUTURE Setting system policy to FUTURE警告If your system communicates with legacy systems, you might face interoperability problems due to the strict setting of the
FUTUREpolicy.
You can also disable only specific ciphers for the SSH protocol through the system-wide cryptographic policies. See the Customizing system-wide cryptographic policies with subpolicies section in the Security hardening document for more information.
- Opting out of system-wide cryptographic policies
To opt out of the system-wide cryptographic policies for your OpenSSH server, specify the cryptographic policy in a drop-in configuration file located in the
/etc/ssh/sshd_config.d/directory, with a two-digit number prefix smaller than 50, so that it lexicographically precedes the50-redhat.conffile, and with a.confsuffix, for example,49-crypto-policy-override.conf.See the
sshd_config(5)man page for more information.To opt out of system-wide cryptographic policies for your OpenSSH client, perform one of the following tasks:
-
For a given user, override the global
ssh_configwith a user-specific configuration in the~/.ssh/configfile. -
For the entire system, specify the cryptographic policy in a drop-in configuration file located in the
/etc/ssh/ssh_config.d/directory, with a two-digit number prefix smaller than 50, so that it lexicographically precedes the50-redhat.conffile, and with a.confsuffix, for example,49-crypto-policy-override.conf.
-
For a given user, override the global