ASD ISM 0484 Configure SSH for secure server access
What it says
The SSH daemon is configured to: - only listen on the required interfaces (ListenAddress xxx.xxx.xxx.xxx) - have a suitable login banner (Banner x) - have a login authentication timeout of no more than 60 seconds (LoginGraceTime 60) - disable host-based authentication (HostbasedAuthentication no) - disable rhosts-based authentication (IgnoreRhosts yes) - disable the ability to log in directly as root (PermitRootLogin no) - disable empty passwords (PermitEmptyPasswords no) - disable connection forwarding (AllowTCPForwarding no) - disable gateway ports (GatewayPorts no) - disable X11 forwarding (X11Forwarding no).
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEnsure SSH settings enhance security by limiting access, disabling risky features, and ensuring safe login practices.
This control is all about setting up a safe digital lock on your servers. If not done, strangers could enter your systems, potentially accessing sensitive information or causing disruptions.
Free. Save your status, tasks and notes.
Why it matters
Without secure SSH settings, unauthorised users could exploit server access, leading to data breaches or operational failures.
How to implement
Your IT team should ensure that the server only listens for connections on necessary network interfaces.
They can do this by editing the SSH configuration file to include the 'ListenAddress' setting with the required IP address.
The IT manager should establish a firm but polite login message.
This can be done by creating a text file with a welcome message and updating the SSH 'Banner' setting to point to this file.
IT staff should set a short grace period for logging in, like 60 seconds.
They can set this by changing the 'LoginGraceTime' in the SSH settings to prevent potential intruders from taking too long.
Ensure that only authorised users have access by disabling the root login directly.
IT can do this by adding 'PermitRootLogin no' to the SSH configuration, forcing users to authenticate as normal users first.
Prevent the use of insecure login methods by turning off host-based and 'rhost' authentication.
This is done by setting 'HostbasedAuthentication no' and 'IgnoreRhosts yes' in the configuration.
Keep it running
Regularly review SSH configurations for changes. Ensure security settings stay aligned with evolving threats and best practices.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
the SSH configuration file.
Look at
details like 'ListenAddress' and 'PermitRootLogin'.
Good evidence
proper settings matching the control requirements.
- Check 2 of 5What an auditor asks for
Good evidence
shows a clear message that complies with organisational policies.
- Check 3 of 5What an auditor asks for
Ask for
the SSH service logs to verify the 'LoginGraceTime' is enforced. Check recorded sessions for time limits.
Good evidence
login attempts have a 60-second window.
- Check 4 of 5What an auditor asks for
Look at
evidence of 'PermitRootLogin' set to 'no'.
Good evidence
outcome shows this practice is documented and implemented.
- Check 5 of 5What an auditor asks for
Ask for
security audit reports on SSH settings.
Look at
conclusions and recommendations. Good reports confirm all insecure practices are disabled or controlled.
Mappings
Closest match in ISO/IEC 27001: A.8.5, Secure authentication technologies and procedures, which this control covers in full and more.
ISO/IEC 27001: 4 mappings
This control is broader than A.8.5.
ISM-0484 outlines SSH daemon settings to secure authentication and remote sessions, specifying measures like LoginGraceTime and disabling host-based auth. Annex A 8.5 requires integration of secure authentication methods and technologies. ISM-0484 meets specific technical requirements under the broader guidance of Annex A 8.5 for SSH-based management.
This control partially meets A.8.9.
ISM-0484 requires specific secure configuration settings for the SSH daemon, such as interface binding and authentication timeouts. Annex A 8.9 mandates that configurations for systems, services, and networks are established, documented, and reviewed, including hardening measures like SSH settings. ISM-0484 provides concrete, service-specific controls within the broader management context covered by Annex A 8.9.
This control partially meets A.8.20.
Annex A 8.20 requires network devices and the services used to manage them to be secured to prevent unauthorised access and protect information. ISM-0484 directly relates by specifying secure SSH daemon configuration settings that harden remote administration channels and reduce the risk of compromise. Annex A 8.20 is broader because it covers many other network device security measures beyond SSH configuration hardening.
This control supports A.5.15.
ISM-0484 ensures secure remote access behaviour for SSH by disabling insecure options like direct root login and empty passwords. Annex A 5.15 requires rules for logical access control aligned with business needs, such as SSH restrictions. ISM-0484 strengthens technical enforcement of these policies, contributing to, but not wholly defining, access control measures required by Annex A 5.15.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.