Technical Security Controls & Risk Management

The Federal Information Systems Act requires government agencies to implement an information security program that effectively manages risk. Under FISMA legislation, the National Institute of Standards and Technology (NIST) specifies the technical security controls required by agencies as mandated by FISMA.

NIST 800-53 Requirements for Secure Shell

SSH Communications Security works closely with NIST to develop best practices for risk and security controls in IT environments where Secure Shell is used. Take advantage of our expertise, tools and products to ensure compliance for your organization.

The Overview

  • NIST SP 800-53 Controls

    Secure Shell Guidance


    Management controls must be implemented for Secure Shell software configurations and user key installation, use, rotation and audit to ensure policy conformance.

  • AUDIT (AU-1)

    Enhanced auditing of SSH should be enabled to track the usage of keys and provide an audit trail of which source user (and client) is using keys to connect to the destination user.


    SSH user key based access should be addressed in the security assessment plan and included in the security assessment and regularly analyzed as part of a continuous monitoring program.


    SSHkeys and SSH configuration files are security-sensitive configuration information. Misconfiguration, modification or unauthorized disclosure may expose serverstounintendedaccessorvulnerabilities. Changes to them should be reviewed, documented and audited.


    SSH user keys are frequently used in systems that copy data to disaster recovery sites and implement switching operations to use disaster recovery sites. The contingency plan should not rely on switching operations to disaster recovery sites if a trust relationship without a command restriction permits access from one site to another, allowing attacks and malware to spread between sites.


    SSH identity keys should be associated with an individual user.

    Policy should prohibit users from sharing private keys, using another user’s private key, or copying/moving a private key to another system.

    Monitoring of key usage should be performed to detect instances where keys are being shared by multiple users, and compromised/shared keys should be rotated. Secure Shell host keys should be used.


    SSH configurations and authorized keys should be checked after maintenance to ensure they are still properly configured and functioning (e.g., as part of continuous monitoring).


    Automated access should be considered when defining and enforcing the authorization boundary. Automated access and SSH key-based access must be considered in the information security architecture. Given that many organizations have more SSH user keys granting access than they have PKI tokens or passwords, they cannot be ignored when developing the information security architecture.


    Access should not be provisioned without proper access agreement. Any authenticators associated with an individual should be terminated upon the individual's employment - this means at minimum removing the related authorized keys from all servers.


    Risk assessment should consider attack propagation risk: if one system is compromised, an attack could spread to other systems using SSH keys (especially if command restrictions are not used), possibly even to backup systems and disaster recovery sites.


    SSH keys should be rotated and reissued on a regular basis.

    SSH user keys should be created only through a controlled provisioning process. Unique host keys should be used.


    SSH connections using key-based authentication should be monitored and connections to detect unauthorized use of authorized keys (e.g., using copied identity keys) in real time. Authorized keys and other SSH configuration files installed without proper authorization should be detected (e.g., using continuous monitoring tools).