Enforce SSH key authentication by disabling password-based SSH access and allowing only approved public keys for the virtual machine. Confirm that every administrator has a working key before you block passwords, then test login and recovery paths. Review which keys are installed, remove stale keys, and ensure emergency access is controlled rather than relying on shared passwords.
What SSH key enforcement changes on an Azure Linux VM
Enforcing ssh key authentication means the VM accepts logins only from users who can present the right private key for an approved public key. In practice, that removes password guessing, password reuse, and most credential-stuffing exposure from the SSH path. On Azure, the control is only safe when you have a verified key for every legitimate admin and a recovery path that does not depend on shared passwords.
For Azure Linux virtual machines, this is usually an access-control decision rather than a tuning choice. You are narrowing the authentication method on the SSH service, so the real question is whether every administrator, automation path, and break-glass process can still function after passwords are disabled. That is why the rollout order matters as much as the setting itself.
It also changes the failure mode of administration. A lost key, revoked key, or misconfigured client can lock out operators just as effectively as an attacker can be blocked. Teams that treat SSH key enforcement as a one-click hardening task often discover the operational edge cases only after a maintenance window has already closed.
How to roll it out without cutting off legitimate access
Start by inventorying who and what still needs SSH access, then confirm each of those users or automation paths has a working key installed on the VM. Test the key login before changing password policy, and keep one controlled recovery method available so you are not depending on an undocumented workaround if something fails.
Once the approved keys are confirmed, disable password-based SSH authentication and verify that the server accepts only key-based logins. Then review the installed public keys themselves, because enforcement is only as strong as the list of keys that remain authorized. Remove stale, duplicated, or orphaned keys promptly, especially after staff changes or temporary access approvals expire.
For Azure-specific operations, the practical concern is not just the guest OS setting but the full administrative path. If an image, extension, automation script, or runbook still assumes password access, you may create a hidden outage even though the SSH daemon is correctly configured. Treat the guest configuration and the access workflow as one control.
When you need to protect a sensitive access path, use a dedicated review point for SSH keys and related admin access. NHIMG’s SSH Key and SSH Certificate Management Guide is useful for thinking about key sprawl, authorized_keys risk, rotation, and orphaned-key removal together rather than as separate tasks.
What to check after passwords are disabled
After enforcement, validate the exact behavior you expect: a valid key should work, an invalid key should fail, and a password prompt should no longer provide a fallback. Check whether every administrative account is covered, whether authorized_keys still contains obsolete material, and whether the VM can still be reached through your approved break-glass method.
Also confirm whether the environment depends on SSH in more than one way. Interactive admin logins, automation jobs, bastion access, and temporary troubleshooting sessions often have different owners. If any of those use the same key set, you need a clear process for revocation and replacement so one compromise does not become a broad access problem.
Look closely at recovery and exception handling. The safest policy is the one you can still operate during an outage, which means documenting how a locked-out administrator regains access without re-enabling passwords for everyone. If that cannot be demonstrated, the control is too brittle for production.
Risk and Threat Considerations
SSH password exposure is attractive because it turns remote administration into a reusable credential problem, especially when the same password or a weak admin secret exists across hosts. On cloud VMs, a single exposed login can become a persistent foothold if the attacker can add or replace authorized keys.
Failure mechanism: Password-based SSH remains available, or stale keys stay authorized, so an attacker can authenticate with stolen or guessed credentials and preserve access by planting a new public key.
Impact: The VM can be managed without valid owner approval, which creates lateral-movement risk, service compromise, and the need to assume the host and any credentials stored on it may have been exposed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | SSH key enforcement depends on issuing, tracking, and revoking usable authenticators. |
| IA-9 — Service Identification and Authentication | SSH access for automation or non-user pathways requires authenticating non-human actors correctly. | |
| Recommendation — Manage SSH keys through issuance, rotation, revocation, and removal of stale credentials. Use distinct service authentication controls for any automated SSH access path. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Disabling passwords and allowing only approved keys is an access-control decision. |
| A.8.5 — Secure authentication | Key-only SSH access is a secure-authentication requirement for the VM login path. | |
| Recommendation — Restrict SSH login methods to approved authenticated access paths only. Require key-based authentication and remove weaker SSH login methods. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The question is about limiting remote access to approved identities and keys. |
| Recommendation — Review and revoke SSH access regularly, including stale keys and exceptions. | ||
Practitioner Guidance
What to verify: Verify the control against real users, not just policy text. You need proof that every legitimate admin, emergency responder, and automation path can still authenticate before passwords are turned off.
Common mistake: Do not confuse “passwords disabled” with “access secured.” If old keys remain, if shared keys are reused across hosts, or if recovery is undefined, the exposure has simply moved from passwords to unmanaged keys.
Decision rule: If you cannot name who owns each installed key and when it should be removed, treat the environment as not yet ready for full enforcement.
Practitioner takeaway: The control is successful only when it reduces access risk without creating an unrecoverable admin path, so key inventory and recovery design matter as much as the SSH setting itself.
Related resources from NHI Mgmt Group
- How do you disable local key authentication for Azure Cosmos DB?
- Why is it crucial to adopt new authentication methods in MCP usage?
- What is the difference between SSH password authentication and public key authentication?
- What is the difference between SSH public key authentication and SSH certificate-based authentication?