SSH's cryptographic host-based authentication is
more secure than .rhosts authentication. However, it is
not recommended that hosts unilaterally trust one another, even
within an organization.
The default SSH configuration disables host-based authentication. The appropriate
configuration is used if no value is set for HostbasedAuthentication.
To explicitly disable host-based authentication, add or correct the
following line in
/etc/ssh/sshd_config.d/00-complianceascode-hardening.conf:
HostbasedAuthentication no
SSH trust relationships mean a compromise on one host can allow an attacker to move trivially to other hosts.
To properly set the group owner of /etc/ssh/sshd_config, run the command:
$ sudo chgrp root /etc/ssh/sshd_config
Service configuration files enable or disable features of their respective services that if configured incorrectly can lead to insecure and vulnerable configurations. Therefore, service configuration files should be owned by the correct group to prevent unauthorized changes.
SSH server private keys, files that match the /etc/ssh/*_key glob, must be
group-owned by root group.
If an unauthorized user obtains the private SSH host key file, the host could be impersonated.
SSH server public keys, files that match the /etc/ssh/*.pub glob, must be
group-owned by root group.
If a public host key file is modified by an unauthorized user, the SSH service may be compromised.
To properly set the owner of /etc/ssh/sshd_config, run the command:
$ sudo chown root /etc/ssh/sshd_config
Service configuration files enable or disable features of their respective services that if configured incorrectly can lead to insecure and vulnerable configurations. Therefore, service configuration files should be owned by the correct group to prevent unauthorized changes.
SSH server private keys, files that match the /etc/ssh/*_key glob, must be owned
by root user.
If an unauthorized user obtains the private SSH host key file, the host could be impersonated.
SSH server public keys, files that match the /etc/ssh/*.pub glob, must be owned
by root user.
If a public host key file is modified by an unauthorized user, the SSH service may be compromised.
To properly set the permissions of /etc/ssh/sshd_config, run the command:
$ sudo chmod 0600 /etc/ssh/sshd_config
Service configuration files enable or disable features of their respective services that if configured incorrectly can lead to insecure and vulnerable configurations. Therefore, service configuration files should be owned by the correct group to prevent unauthorized changes.
SSH server private keys - files that match the /etc/ssh/*_key glob, have to have restricted permissions.
If those files are owned by the root user and the root group, they have to have the 0600 permission or stricter.
If an unauthorized user obtains the private SSH host key file, the host could be impersonated.
To properly set the permissions of /etc/ssh/*.pub, run the command:
$ sudo chmod 0644 /etc/ssh/*.pub
If a public host key file is modified by an unauthorized user, the SSH service may be compromised.
The /etc/ssh/sshd_config.d/50-redhat.conf file must exist as it contains important settings to secure SSH.
The file must exist to configure SSH correctly.
By default, inbound connections to SSH's port are allowed. If
the SSH server is not being used, this exception should be removed from the
firewall configuration.
To configure firewalld to prevent access, run the following command(s):
firewall-cmd --permanent --remove-service=ssh
If inbound SSH connections are not expected, disallowing access to the SSH port will avoid possible exploitation of the port by an attacker.
If the SSH server is in use, inbound connections to SSH's port should be allowed to permit
remote access through SSH. In more restrictive firewalld settings, the SSH port should be
added to the proper firewalld zone in order to allow SSH remote access.
To configure firewalld to allow ssh access, run the following command(s):
firewall-cmd --permanent --add-service=sshThen run the following command to load the newly created rule(s):
firewall-cmd --reload
If inbound SSH connections are expected, adding the SSH port to the proper firewalld zone will allow remote access through the SSH port.
By default, inbound connections to SSH's port are allowed. If the SSH
server is not being used, this exception should be removed from the
firewall configuration.
Edit the files /etc/sysconfig/iptables and
/etc/sysconfig/ip6tables (if IPv6 is in use). In each file, locate
and delete the line:
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPTThis is unusual, as SSH is a common method for encrypted and authenticated remote access.
If inbound SSH connections are not expected, disallowing access to the SSH port will avoid possible exploitation of the port by an attacker.
The openssh-clients package can be installed with the following command:
$ sudo dnf install openssh-clients
This package includes utilities to make encrypted connections and transfer files securely to SSH servers.
The openssh-server package should be installed.
The openssh-server package can be installed with the following command:
$ sudo dnf install openssh-server
Without protection of the transmitted information, confidentiality, and integrity may be compromised because unprotected communications can be intercepted and either read or altered.
The openssh-server package should be removed.
The openssh-server package can be removed with the following command:
$ sudo dnf remove openssh-server
Without protection of the transmitted information, confidentiality, and integrity may be compromised because unprotected communications can be intercepted and either read or altered.
The openssh package should be installed.
The openssh package can be installed with the following command:
$ sudo dnf install openssh
Without protection of the transmitted information, confidentiality, and integrity may be compromised because unprotected communications can be intercepted and either read or altered.
The openssh package should be removed.
The openssh package can be removed with the following command:
$ sudo dnf remove openssh
Without protection of the transmitted information, confidentiality, and integrity may be compromised because unprotected communications can be intercepted and either read or altered.
The SSH server service, sshd, is commonly needed. However, if it can be disabled, do so. This is unusual, as SSH is a common method for encrypted and authenticated remote access.
The SSH server service, sshd, is commonly needed.
The sshd service can be enabled with the following command:
$ sudo systemctl enable sshd.service
Without protection of the transmitted information, confidentiality, and
integrity may be compromised because unprotected communications can be
intercepted and either read or altered.
This checklist item applies to both internal and external networks and all types
of information system components from which information can be transmitted (e.g., servers,
mobile devices, notebook computers, printers, copiers, scanners, etc). Communication paths
outside the physical protection of a controlled boundary are exposed to the possibility
of interception and modification.
The RekeyLimit parameter specifies how often the session key is renegotiated, both in terms of amount of data that may be transmitted and the time elapsed. To decrease the default limits, put line RekeyLimit $var_ssh_client_rekey_limit_size $var_ssh_client_rekey_limit_time to file /etc/ssh/ssh_config.d/02-rekey-limit.conf. Make sure that there is no other RekeyLimit configuration preceding the include directive in the main config file /etc/ssh/ssh_config. Check also other files in /etc/ssh/ssh_config.d directory. Files are processed according to lexicographical order of file names. Make sure that there is no file processed before 02-rekey-limit.conf containing definition of RekeyLimit.
By decreasing the limit based on the amount of data and enabling time-based limit, effects of potential attacks against encryption keys are limited.
To set up SSH client to use entropy from a high-quality source, make sure that the appropriate shell environment variable is configured. The SSH_USE_STRONG_RNG environment variable determines how many bytes of entropy to use. Make sure that the file /etc/profile.d/cc-ssh-strong-rng.csh contains line
setenv SSH_USE_STRONG_RNG 32.
Some SSH implementations use the openssl library for entropy, which by default, doesn't use high-entropy sources. Randomness is needed to generate considerably more secure data-encryption keys. Plaintext padding, initialization vectors in encryption algorithms, and high-quality entropy eliminates the possibility that the output of the random number generator used by SSH would be known to potential attackers.
To set up SSH client to use entropy from a high-quality source, make sure that the appropriate shell environment variable is configured. The SSH_USE_STRONG_RNG environment variable determines how many bytes of entropy to use. Make sure that the file /etc/profile.d/cc-ssh-strong-rng.sh contains line
export SSH_USE_STRONG_RNG=32.
Some SSH implementations use the openssl library for entropy, which by default, doesn't use high-entropy sources. Randomness is needed to generate considerably more secure data-encryption keys. Plaintext padding, initialization vectors in encryption algorithms, and high-quality entropy eliminates the possibility that the output of the random number generator used by SSH would be known to potential attackers.
When creating SSH key pairs, always use a passcode.
You can create such keys with the following command:
$ sudo ssh-keygen -n [passphrase]Red Hat Enterprise Linux 10, for certificate-based authentication, must enforce authorized access to the corresponding private key.
If an unauthorized user obtains access to a private key without a passcode, that user would have unauthorized access to any system where the associated public key has been installed.
Verify the SSH private key files have a passcode. For each private key stored on the system, use the following command:
$ sudo ssh-keygen -y -f /path/to/fileIf the contents of the key are displayed, without asking a passphrase this is a finding.
If an unauthorized user obtains access to a private key without a passcode, that user would have unauthorized access to any system where the associated public key has been installed.
Only SSH protocol version 2 connections should be permitted. The default setting in /etc/ssh/sshd_config is correct, and can be verified by ensuring that the following line appears:
Protocol 2
SSH protocol version 1 is an insecure implementation of the SSH protocol and has many well-known vulnerability exploits. Exploits of the SSH daemon could provide immediate root access to the system.
Compression is useful for slow network connections over long distances but can cause performance issues on local LANs. If use of compression is required, it should be enabled only after a user has authenticated; otherwise, it should be disabled. To disable compression or delay compression until after a user has successfully authenticated, add or correct the following line in the /etc/ssh/sshd_config file:
Compression $var_sshd_disable_compression
If compression is allowed in an SSH connection prior to authentication, vulnerabilities in the compression software could result in compromise of the system from an unauthenticated connection, potentially with root privileges.
Disallow SSH login with empty passwords.
The default SSH configuration disables logins with empty passwords. The appropriate
configuration is used if no value is set for PermitEmptyPasswords.
To explicitly disallow SSH login from accounts with empty passwords,
add or correct the following line in
/etc/ssh/sshd_config.d/00-complianceascode-hardening.conf:
PermitEmptyPasswords noAny accounts with empty passwords should be disabled immediately, and PAM configuration should prevent users from being able to assign themselves empty passwords.
Configuring this setting for the SSH daemon provides additional assurance that remote login via SSH will require a password, even in the event of misconfiguration elsewhere.
Unless needed, SSH should not permit extraneous or unnecessary
authentication mechanisms like GSSAPI.
The default SSH configuration disallows authentications based on GSSAPI. The appropriate
configuration is used if no value is set for GSSAPIAuthentication.
To explicitly disable GSSAPI authentication, add or correct the following line in
/etc/ssh/sshd_config.d/00-complianceascode-hardening.conf:
GSSAPIAuthentication no
GSSAPI authentication is used to provide additional authentication mechanisms to applications. Allowing GSSAPI authentication through SSH exposes the system's GSSAPI to remote hosts, increasing the attack surface of the system.
Unless needed, SSH should not permit extraneous or unnecessary
authentication mechanisms like Kerberos.
The default SSH configuration disallows authentication validation through Kerberos.
The appropriate configuration is used if no value is set for KerberosAuthentication.
To explicitly disable Kerberos authentication, add or correct the following line in
/etc/ssh/sshd_config.d/00-complianceascode-hardening.conf:
KerberosAuthentication no
Kerberos authentication for SSH is often implemented using GSSAPI. If Kerberos is enabled through SSH, the SSH daemon provides a means of access to the system's Kerberos implementation. Configuring these settings for the SSH daemon provides additional assurance that remote logon via SSH will not use unused methods of authentication, even in the event of misconfiguration elsewhere.
Unless needed, SSH should not permit extraneous or unnecessary authentication mechanisms. To disable PubkeyAuthentication authentication, add or correct the following line in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf:
PubkeyAuthentication no
PubkeyAuthentication authentication is used to provide additional authentication mechanisms to applications. Allowing PubkeyAuthentication authentication through SSH allows users to generate their own authentication tokens, increasing the attack surface of the system.
SSH can emulate the behavior of the obsolete rsh
command in allowing users to enable insecure access to their
accounts via .rhosts files.
The default SSH configuration disables support for .rhosts. The appropriate
configuration is used if no value is set for IgnoreRhosts.
To explicitly disable support for .rhosts files, add or correct the following line in
/etc/ssh/sshd_config.d/00-complianceascode-hardening.conf:
IgnoreRhosts yes
SSH trust relationships mean a compromise on one host can allow an attacker to move trivially to other hosts.
SSH can allow authentication through the obsolete rsh
command through the use of the authenticating user's SSH keys. This should be disabled.
To ensure this behavior is disabled, add or correct the
following line in /etc/ssh/sshd_config:
RhostsRSAAuthentication no
Configuring this setting for the SSH daemon provides additional assurance that remote login via SSH will require a password, even in the event of misconfiguration elsewhere.
The root user should never be allowed to login to a system directly over a network. To disable root login via SSH, add or correct the following line in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf:
PermitRootLogin no
Even though the communications channel may be encrypted, an additional layer of security is gained by extending the policy of not logging directly on as root. In addition, logging in with a user-specific account provides individual accountability of actions performed on the system and also helps to minimize direct attack attempts on root's password.
To disable password-based root logins over SSH, add or correct the following line in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf:
PermitRootLogin prohibit-password
Even though the communications channel may be encrypted, an additional layer of security is gained by preventing use of a password. This also helps to minimize direct attack attempts on root's password.
The AllowTcpForwarding parameter specifies whether TCP forwarding is permitted. To disable TCP forwarding, add or correct the following line in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf:
AllowTcpForwarding no
Leaving port forwarding enabled can expose the organization to security risks and back-doors.
SSH can allow system users to connect to systems if a cache of the remote
systems public keys is available. This should be disabled.
To ensure this behavior is disabled, add or correct the following line in
/etc/ssh/sshd_config.d/00-complianceascode-hardening.conf:
IgnoreUserKnownHosts yes
Configuring this setting for the SSH daemon provides additional assurance that remote login via SSH will require a password, even in the event of misconfiguration elsewhere.
The X11Forwarding parameter provides the ability to tunnel X11 traffic
through the connection to enable remote graphic connections.
SSH has the capability to encrypt remote X11 connections when SSH's
X11Forwarding option is enabled.
The default SSH configuration disables X11Forwarding. The appropriate
configuration is used if no value is set for X11Forwarding.
To explicitly disable X11 Forwarding, add or correct the following line in
/etc/ssh/sshd_config.d/00-complianceascode-hardening.conf:
X11Forwarding no
Disable X11 forwarding unless there is an operational requirement to use X11 applications directly. There is a small risk that the remote X11 servers of users who are logged in via SSH with X11 forwarding could be compromised by other users on the X11 server. Note that even if X11 forwarding is disabled, users can always install their own forwarders.
Ensure that users are not able to override environment variables of the SSH daemon.
The default SSH configuration disables environment processing. The appropriate
configuration is used if no value is set for PermitUserEnvironment.
To explicitly disable Environment options, add or correct the following
/etc/ssh/sshd_config.d/00-complianceascode-hardening.conf:
PermitUserEnvironment no
SSH environment options potentially allow users to bypass access restriction in some configurations.
Sites setup to use Kerberos or other GSSAPI Authenticaion require setting sshd to accept this authentication. To enable GSSAPI authentication, add or correct the following line in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf:
GSSAPIAuthentication yes
Kerberos authentication for SSH is often implemented using GSSAPI. If Kerberos is enabled through SSH, the SSH daemon provides a means of access to the system's Kerberos implementation. Vulnerabilities in the system's Kerberos implementations may be subject to exploitation. For enterprises, Kerberos is often enabled and used with GSSAPI for centralized user account management which may necessitate enabling of GSSAPI functionality in SSH.
UsePAM Enables the Pluggable Authentication Module interface. If set to “yes” this will enable PAM authentication using ChallengeResponseAuthentication and PasswordAuthentication in addition to PAM account and session module processing for all authentication types. To enable PAM authentication, add or correct the following line in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf:
UsePAM yes
When UsePAM is set to yes, PAM runs through account and session types properly. This is important if you want to restrict access to services based off of IP, time or other factors of the account. Additionally, you can make sure users inherit certain environment variables on login or disallow access to the server.
Enable SSH login with public keys.
The default SSH configuration enables authentication based on public keys. The appropriate
configuration is used if no value is set for PubkeyAuthentication.
To explicitly enable Public Key Authentication, add or correct the following
/etc/ssh/sshd_config.d/00-complianceascode-hardening.conf:
PubkeyAuthentication yes
Without the use of multifactor authentication, the ease of access to privileged functions is greatly increased. Multifactor authentication requires using two or more factors to achieve authentication. A privileged account is defined as an information system account with authorizations of a privileged user. The DoD CAC with DoD-approved PKI is an example of multifactor authentication.
SSHs StrictModes option checks file and ownership permissions in
the user's home directory .ssh folder before accepting login. If world-
writable permissions are found, logon is rejected.
The default SSH configuration has StrictModes enabled. The appropriate
configuration is used if no value is set for StrictModes.
To explicitly enable StrictModes in SSH, add or correct the following line in
/etc/ssh/sshd_config.d/00-complianceascode-hardening.conf:
StrictModes yes
If other users have access to modify user-specific SSH configuration files, they may be able to log into the system as another user.
By default, remote X11 connections are not encrypted when initiated
by users. SSH has the capability to encrypt remote X11 connections when SSH's
X11Forwarding option is enabled.
To enable X11 Forwarding, add or correct the following line in
/etc/ssh/sshd_config.d/00-complianceascode-hardening.conf:
X11Forwarding yes
Non-encrypted X displays allow an attacker to capture keystrokes and to execute commands remotely.
By default, the SSH configuration allows any user with an account to access the system. 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 variable gives the system administrator the option of allowing specific users to ssh into the system. The list consists of space separated user names. Numeric user IDs are not recognized with this variable. If a system administrator wants to restrict user access further by specifically allowing a user's access only from a particular host, the entry can be specified in the form of user@host. - AllowGroups variable gives the system administrator the option of allowing specific groups of users to ssh into the system. The list consists of space separated group names. Numeric group IDs are not recognized with this variable. - DenyUsers variable gives the system administrator the option of denying specific users to ssh into the system. The list consists of space separated user names. Numeric user IDs are not recognized with this variable. If a system administrator wants to restrict user access further by specifically denying a user's access from a particular host, the entry can be specified in the form of user@host. - DenyGroups variable gives the system administrator the option of denying specific groups of users to ssh into the system. The list consists of space separated group names. Numeric group IDs are not recognized with this variable.
Specifying which accounts are allowed SSH access into the system reduces the possibility of unauthorized access to the system.
Ensure that SSH will display the date and time of the last successful account logon.
The default SSH configuration enables print of the date and time of the last login.
The appropriate configuration is used if no value is set for PrintLastLog.
To explicitly enable LastLog in SSH, add or correct the following line in
/etc/ssh/sshd_config.d/00-complianceascode-hardening.conf:
PrintLastLog yes
Providing users feedback on when account accesses last occurred facilitates user recognition and reporting of unauthorized account use.
The RekeyLimit parameter specifies how often
the session key of the is renegotiated, both in terms of
amount of data that may be transmitted and the time
elapsed.
To decrease the default limits, add or correct the following line in
/etc/ssh/sshd_config.d/00-complianceascode-hardening.conf:
RekeyLimit $var_rekey_limit_size $var_rekey_limit_time
By decreasing the limit based on the amount of data and enabling time-based limit, effects of potential attacks against encryption keys are limited.
SSH allows administrators to set a network responsiveness timeout interval.
After this interval has passed, the unresponsive client will be automatically logged out.
To set this timeout interval, edit the following line in /etc/ssh/sshd_config as
follows:
ClientAliveInterval $sshd_idle_timeout_value
Terminating an idle ssh session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been let unattended.
The SSH server sends at most ClientAliveCountMax messages during a SSH session and waits for a response from the SSH client. The option ClientAliveInterval configures timeout after each ClientAliveCountMax message. If the SSH server does not receive a response from the client, then the connection is considered unresponsive and terminated. For SSH earlier than v8.2, a ClientAliveCountMax value of 0 causes a timeout precisely when the ClientAliveInterval is set. Starting with v8.2, a value of 0 disables the timeout functionality completely. If the option is set to a number greater than 0, then the session will be disconnected after ClientAliveInterval * ClientAliveCountMax seconds without receiving a keep alive message.
This ensures a user login will be terminated as soon as the ClientAliveInterval is reached.
The SSH server sends at most ClientAliveCountMax messages during a SSH session and waits for a response from the SSH client. The option ClientAliveInterval configures timeout after each ClientAliveCountMax message. If the SSH server does not receive a response from the client, then the connection is considered unresponsive and terminated. To ensure the SSH timeout occurs precisely when the ClientAliveInterval is set, set the ClientAliveCountMax to value of 0 in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf:
This ensures a user login will be terminated as soon as the ClientAliveInterval is reached.
The LoginGraceTime parameter to the SSH server specifies the time allowed for successful authentication to the SSH server. The longer the Grace period is the more open unauthenticated connections can exist. Like other session controls in this session the Grace Period should be limited to appropriate limits to ensure the service is available for needed access.
Setting the LoginGraceTime parameter to a low number will minimize the risk of successful brute force attacks to the SSH server. It will also limit the number of concurrent unauthenticated connections.
The INFO parameter specifices that record login and logout activity will be logged.
The default SSH configuration sets the log level to INFO. The appropriate
configuration is used if no value is set for LogLevel.
To explicitly specify the log level in SSH, add or correct the following line in
/etc/ssh/sshd_config.d/00-complianceascode-hardening.conf:
LogLevel INFO
SSH provides several logging levels with varying amounts of verbosity. DEBUG is specifically not recommended other than strictly for debugging SSH communications since it provides so much data that it is difficult to identify important security information. INFO level is the basic level that only records login activity of SSH users. In many situations, such as Incident Response, it is important to determine when a particular user was active on a system. The logout record can eliminate those users who disconnected, which helps narrow the field.
The VERBOSE parameter configures the SSH daemon to record login and logout activity. To specify the log level in SSH, add or correct the following line in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf:
LogLevel VERBOSE
SSH provides several logging levels with varying amounts of verbosity. DEBUG is specifically not recommended other than strictly for debugging SSH communications since it provides so much data that it is difficult to identify important security information. INFO or VERBOSE level is the basic level that only records login activity of SSH users. In many situations, such as Incident Response, it is important to determine when a particular user was active on a system. The logout record can eliminate those users who disconnected, which helps narrow the field.
The MaxAuthTries parameter specifies the maximum number of authentication attempts permitted per connection. Once the number of failures reaches half this value, additional failures are logged. to set MaxAUthTries edit /etc/ssh/sshd_config as follows:
MaxAuthTries $sshd_max_auth_tries_value
Setting the MaxAuthTries parameter to a low number will minimize the risk of successful brute force attacks to the SSH server.
The MaxSessions parameter specifies the maximum number of open sessions permitted from a given connection. To set MaxSessions edit /etc/ssh/sshd_config as follows:
MaxSessions $var_sshd_max_sessions
To protect a system from denial of service due to a large number of concurrent sessions, use the rate limiting function of MaxSessions to protect availability of sshd logins and prevent overwhelming the daemon.
The MaxStartups parameter specifies the maximum number of concurrent unauthenticated connections to the SSH daemon. Additional connections will be dropped until authentication succeeds or the LoginGraceTime expires for a connection. To configure MaxStartups, you should add or edit the following line in the /etc/ssh/sshd_config file:
MaxStartups $var_sshd_set_maxstartups
To protect a system from denial of service due to a large number of pending authentication connection attempts, use the rate limiting function of MaxStartups to protect availability of sshd logins and prevent overwhelming the daemon.
Limit the ciphers to those algorithms which are FIPS-approved. Counter (CTR) mode is also preferred over cipher-block chaining (CBC) mode. The following line in /etc/ssh/sshd_config demonstrates use of FIPS-approved ciphers:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbcThe man page sshd_config(5) contains a list of supported ciphers. The rule is parametrized to use the following ciphers:
$sshd_approved_ciphers.
Unapproved mechanisms that are used for authentication to the cryptographic module are not verified and therefore
cannot be relied upon to provide confidentiality or integrity, and system data may be compromised.
Operating systems utilizing encryption are required to use FIPS-compliant mechanisms for authenticating to
cryptographic modules.
FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules
utilize authentication that meets industry and government requirements. For government systems, this allows
Security Levels 1, 2, 3, or 4 for use on Red Hat Enterprise Linux 10.
Limit the ciphers to those algorithms which are FIPS-approved. The following line in /etc/ssh/sshd_config demonstrates use of FIPS-approved ciphers:
Ciphers aes256-ctr,aes192-ctr,aes128-ctrThis rule ensures that there are configured ciphers mentioned above (or their subset), keeping the given order of algorithms.
Unapproved mechanisms that are used for authentication to the cryptographic module are not verified and therefore
cannot be relied upon to provide confidentiality or integrity, and system data may be compromised.
Operating systems utilizing encryption are required to use FIPS-compliant mechanisms for authenticating to
cryptographic modules.
FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules
utilize authentication that meets industry and government requirements. For government systems, this allows
Security Levels 1, 2, 3, or 4 for use on Red Hat Enterprise Linux 10.
Limit the key exchange algorithms to those which are FIPS-approved. Add or modify the following line in
This rule ensures that only the key exchange algorithms mentioned above (or their subset) are configured for use, keeping the given order of algorithms.DoD information systems are required to use FIPS-approved key exchange algorithms. The system will attempt to use the first algorithm presented by the client that matches the server list. Listing the values "strongest to weakest" is a method to ensure the use of the strongest algorithm available to secure the SSH connection.
Limit the MACs to those hash algorithms which are FIPS-approved. The following line in /etc/ssh/sshd_config demonstrates use of FIPS-approved MACs:
MACs hmac-sha2-512,hmac-sha2-256,hmac-sha1The man page sshd_config(5) contains a list of supported MACs. The rule is parametrized to use the following MACs:
$sshd_approved_macs.
DoD Information Systems are required to use FIPS-approved cryptographic hash functions. The only SSHv2 hash algorithms meeting this requirement is SHA2.
Limit the MACs to those hash algorithms which are FIPS-approved. The following line in /etc/ssh/sshd_config demonstrates use of FIPS-approved MACs:
MACs hmac-sha2-512,hmac-sha2-256This rule ensures that there are configured MACs mentioned above (or their subset), keeping the given order of algorithms.
DoD Information Systems are required to use FIPS-approved cryptographic hash functions. The only SSHv2 hash algorithms meeting this requirement is SHA2.
Make sure to have the Include /etc/ssh/sshd_config.d/*.conf line in the /etc/ssh/sshd_config file. Ideally, don't have any active configuration directives in that file, and distribute the service configuration to several files in the /etc/ssh/sshd_config.d directory.
This form of distributed configuration is considered as a good practice, and as other sshd rules assume that directives in files in the /etc/ssh/sshd_config.d config directory are effective, there has to be a rule that ensures this. Aside from that, having multiple configuration files makes the SSH Server configuration changes easier to partition according to the reason that they were introduced, and therefore it should help to perform merges of hardening updates.
When enabled, SSH will create an unprivileged child process that has the privilege of the authenticated user. To enable privilege separation in SSH, add or correct the following line in the /etc/ssh/sshd_config file:
UsePrivilegeSeparation $var_sshd_priv_separation
SSH daemon privilege separation causes the SSH process to drop root privileges when not needed which would decrease the impact of software vulnerabilities in the unprivileged section.
Limit the ciphers to strong algorithms. Counter (CTR) mode is also preferred over cipher-block chaining (CBC) mode. The following line in /etc/ssh/sshd_config demonstrates use of those ciphers:
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctrThe man page sshd_config(5) contains a list of supported ciphers.
Based on research conducted at various institutions, it was determined that the symmetric portion of the SSH Transport Protocol (as described in RFC 4253) has security weaknesses that allowed recovery of up to 32 bits of plaintext from a block of ciphertext that was encrypted with the Cipher Block Chaining (CBD) method. From that research, new Counter mode algorithms (as described in RFC4344) were designed that are not vulnerable to these types of attacks and these algorithms are now recommended for standard use.
Limit the Key Exchange to strong algorithms. The following line in /etc/ssh/sshd_config demonstrates use of those:
KexAlgorithms $sshd_strong_kex
Key exchange is any method in cryptography by which cryptographic keys are exchanged between two parties, allowing use of a cryptographic algorithm. If the sender and receiver wish to exchange encrypted messages, each must be equipped to encrypt messages to be sent and decrypt messages received
Limit the MACs to strong hash algorithms. The following line in /etc/ssh/sshd_config demonstrates use of those MACs:
MACs $sshd_strong_macs
MD5 and 96-bit MAC algorithms are considered weak and have been shown to increase exploitability in SSH downgrade attacks. Weak algorithms continue to have a great deal of attention as a weak spot that can be exploited with expanded computing power. An attacker that breaks the algorithm could take advantage of a MiTM position to decrypt the SSH tunnel and capture credentials and information
To set up SSH server to use entropy from a high-quality source, edit the /etc/sysconfig/sshd file. The SSH_USE_STRONG_RNG configuration value determines how many bytes of entropy to use, so make sure that the file contains line
SSH_USE_STRONG_RNG=32
SSH implementation in Red Hat Enterprise Linux 10 uses the openssl library, which doesn't use high-entropy sources by default. Randomness is needed to generate data-encryption keys, and as plaintext padding and initialization vectors in encryption algorithms, and high-quality entropy elliminates the possibility that the output of the random number generator used by SSH would be known to potential attackers.
The SSH daemon should prevent remote hosts from connecting to the proxy
display.
The default SSH configuration for X11UseLocalhost is yes,
which prevents remote hosts from connecting to the proxy display.
To explicitly prevent remote connections to the proxy display, add or correct
the following line in
/etc/ssh/sshd_config.d/00-complianceascode-hardening.conf:
X11UseLocalhost yes
When X11 forwarding is enabled, there may be additional exposure to the server and client displays if the sshd proxy display is configured to listen on the wildcard address. By default, sshd binds the forwarding server to the loopback address and sets the hostname part of the DISPLAY environment variable to localhost. This prevents remote hosts from connecting to the proxy display.
SSHD should follow the system cryptographic policy. In order to accomplish this the SSHD configuration should include the system
Without cryptographic integrity protections, information can be altered by unauthorized users without detection.