Skip to main content

This section of the ISM provides guidance on Secure Shell.

Using Secure Shell

When using ICT equipment or software that implements SSH, security controls for using AACPs also need to be consulted in the ASD Approved Cryptographic Protocols section of these guidelines.

Configuring Secure Shell

SSH version 1 was found to have a number of security vulnerabilities. As such, it was replaced by SSH version 2. A number of security risks also exist when SSH is configured in an insecure manner. For example, forwarding connections and access privileges, using host-based authentication, and permitting system administrator logins. The configuration settings below are based on OpenSSH. Organisations using other implementations of SSH should adapt these settings to suit their SSH implementation.

Security Control: 1506; Revision: 0; Updated: Sep-18; Applicability: O, P, S, TS
The use of SSH version 1 is disabled.

Security Control: 0484; Revision: 4; Updated: Sep-18; Applicability: O, P, S, TS
The configuration settings in the following table are implemented for the SSH daemon.

Configuration

Description

ListenAddress xxx.xxx.xxx.xxx

On machines with multiple interfaces, configure the SSH daemon to listen only on the required interfaces

AllowTCPForwarding no

Disable connection forwarding

GatewayPorts no

Disable gateway ports

PermitRootLogin no

Disable the ability to login directly as root

HostbasedAuthentication no

Disable host-based authentication

IgnoreRhosts yes

Disable rhosts-based authentication

PermitEmptyPasswords no

Do not allow empty passphrases

Banner x

Configure a suitable login banner

LoginGraceTime xx

Configure a login authentication timeout of no more than 60 seconds

X11Forwarding no

Disable X11 forwarding

Authentication mechanisms

Public key-based authentication schemes offer stronger authentication than passphrase-based authentication schemes due to passphrases being more susceptible to guessing attacks. Therefore, if passphrases are used, counter-measures should be put in place to reduce the chance of a successful brute force attack.

Security Control: 0485; Revision: 3; Updated: Sep-18; Applicability: O, P, S, TS
Public key-based authentication is used for SSH connections.

Security Control: 1449; Revision: 1; Updated: Sep-18; Applicability: O, P, S, TS
SSH private keys are protected with a passphrase or a key encryption key.

Automated remote access

If using logins without a passphrase for automated purposes, a number of security risks may arise, specifically:

  • if access from unknown Internet Protocol (IP) addresses is not restricted, an adversary could automatically authenticate to systems without needing to know any passphrases
  • if port forwarding is not disabled, or it is not configured securely, access may be gained to forwarded ports thereby creating a communication channel between an adversary and a host
  • if agent credential forwarding is enabled, an adversary could connect to the stored authentication credentials and use them to connect to other trusted hosts, or even intranet hosts if port forwarding has been allowed as well
  • if X11 display remoting is not disabled, an adversary could gain control of displays as well as keyboard and mouse control functions
  • if console access is allowed, every user who logs into the console could run programs that are normally restricted to authenticated users.

To assist in mitigating these security risks, it is essential that the ‘forced command’ option is used to specify what command is executed and parameter checked is enabled.

Security Control: 0487; Revision: 3; Updated: Sep-18; Applicability: O, P, S, TS
When using logins without a passphrase for automated purposes, the following are disabled:

  • access from IP addresses that do not require access
  • port forwarding
  • agent credential forwarding
  • X11 display remoting
  • console access.

Security Control: 0488; Revision: 3; Updated: Sep-18; Applicability: O, P, S, TS
If using remote access without the use of a passphrase, the ‘forced command’ option is used to specify what command is executed and parameter checked is enabled.

SSH-agent

SSH-agent or other similar key caching programs hold and manage private keys stored on workstations and respond to requests from remote systems to verify these keys. When an SSH-agent launches, it requests the user’s passphrase to unlock the user’s private key. Subsequent access to remote systems is performed by the agent and does not require the user to re-enter their passphrase. Screen locks and expiring key caches ensure that the user’s private key is not left unlocked for a long period of time. Furthermore, to limit the exposure of credentials, agent credential forwarding should only be enabled when SSH traversal is required.

Security Control: 0489; Revision: 4; Updated: Sep-18; Applicability: O, P, S, TS
When SSH-agent or other similar key caching programs are used, it is only on workstations and servers with screen locks, key caches are set to expire within four hours of inactivity, and agent credential forwarding is enabled only when SSH traversal is required.

Further information

Further information on SSH can be found in IETF RFC 4252 and its updates:

Further information on configuring OpenSSH can be found at https://www.openssh.com/manual.html and https://man.openbsd.org/sshd_config.