How to Harden Ubuntu SSH: From static keys to cloud identity

30 years after its introduction, Secure Shell (SSH) remains the ubiquitous gateway for administration, making it a primary target for brute force attacks and lateral movement within enterprise environments. For system administrators and security architects operating under the weight of regulatory frameworks like SOC2, HIPAA, and PCI-DSS, default SSH configurations are an “open door” that represents an unacceptable risk. As such, accessibility often comes at the cost of security, permitting practices like root login and password authentication that significantly expand the attack surface. At Canonical, we have been focusing on developing solutions to close these gaps, enforcing a “defense-in-depth” strategy that aligns strict access control with centralized identity management.

Linking identity systems to SSH

Traditionally, Linux authentication relied on static credentials stored in /etc/passwd or unmanaged SSH keys scattered across authorized_keys files. At an enterprise scale, this creates massive “identity debt”, with orphaned keys remaining on servers long after employees depart, creating shadow access paths.

To eliminate this vulnerability, SSH should integrate directly with authoritative identity sources. For on-premise environments, systems like System Security Services Daemon (SSSD) can serve as the bridge to Active Directory. When Ubuntu systems join a domain, SSSD handles the authentication exchange, validating Kerberos tickets and automatically creating home directories. This ensures that SSH access privileges are dynamically tied to Active Directory group memberships, instantly revoking access when a user is disabled in the central directory.

How can you use IdPs to authenticate SSH sessions?

For organizations transitioning to cloud based identity providers (IdPs) like Microsoft Entra ID or Google Cloud IAM, we developed authd. This service modernizes the Linux desktop and server by utilizing a modular broker architecture to facilitate authentication against cloud IdPs.

For SSH, authd leverages the OAuth 2.0 Device Authorization Grant (RFC 8628). Since SSH sessions often occur on headless servers lacking a web browser, authd initiates a device flow where the user authenticates via a secondary device (such as a smartphone or a laptop) using their IdP credentials. This architecture allows Ubuntu to enforce Multi-Factor Authentication (MFA) and conditional access policies defined at the IdP level for every SSH login. By centralizing SSH authentication through authd, we eliminate the reliance on static public keys, ensuring that every access request generates an audit trail linked to a managed cloud identity.

Meeting your compliance and cryptographic requirements

For tightly regulated sectors, satisfying compliance controls is not optional. Ubuntu Pro, Canonical’s comprehensive subscription for open source security, provides the infrastructure required to meet stringent standards such as NIST, DISA-STIG, and PCI-DSS. These frameworks mandate rigorous technical controls regarding authentication assurance levels and session management.

With Ubuntu Pro, organizations can automate the application of security benchmarks and hardening profiles across their fleet. This ensures that the cryptographic exchanges and key management protocols underlying SSH connections adhere to the validated standards required for audits 10. We provide the tools to ensure that your gateway security is not just theoretical, but compliant by design.

Can you enforce policies at scale?

Defining a secure configuration is only half the battle. Enforcing it across thousands of nodes is the real challenge. With Adsys, administrators can extend Group Policy Objects (GPOs) to Ubuntu clients.

Using ADsys, we enable the enforcement of security policies and the execution of scripts at system startup or login. This allows security teams to centrally mandate SSH configurations, such as disabling root login or enforcing protocol versions, ensuring that no machine drifts from the approved security baseline. Through centralized privilege management, we can also grant or revoke sudo rights for specific AD groups without manually editing local files, strictly adhering to the Principle of Least Privilege.

Security checklist: hardening SSH

To reduce the attack surface of your Ubuntu infrastructure, we recommend implementing the following hardening measures.

• Disable root login: set PermitRootLogin no in sshd_config to force user accountability.
• Eliminate passwords: set PasswordAuthentication no and mandate public key or IdP-based authentication.
• Enforce MFA: integrate libpam-google-authenticator or use authd with Entra ID/Google IAM for multi-factor verification.
• Restrict network access: use firewalls to allow SSH connections only from trusted IP ranges or VPNs 15.
• Active monitoring: configure Fail2Ban to monitor authentication logs and automatically ban IP addresses exhibiting brute-force behavior.
• Change default ports: configure SSH to listen on a non-standard port (e.g., 2222) to reduce noise from automated scanners.

Read more in our identity management whitepaper

In our newly released whitepaper we provide actionable blueprints and technical specifications to architect, define, and enforce robust identity management controls across your entire server and desktop fleet, regardless of operating system.

We provide a technical examination of modern identity paradigms, including detailed configurations for managing access to cloud and on-premise Linux infrastructure, and practical strategies for seamless and secure integration with legacy AD Domain Services. Furthermore, the paper offers a detailed analysis of the advantages and implementation steps for using SSH certificates for frictionless, auditable SSH authentication, moving beyond simple key management. 

Read the Ubuntu Enterprise Identity Management whitepaper.

Further reading

• ADSys documentation
• Authd documentation
• Authd for Entra ID on Snapcraft
• Authd for Google IAM on Snapcraft
• Authd for OIDC on Snapcraft