Why should Azure Linux VMs use SSH keys instead of password authentication?

Why key-based SSH sign-in is the safer default for Azure Linux VMs

SSH keys reduce the attack surface of remote logins because they replace reusable passwords with cryptographic proof. That matters on internet-reachable Linux VMs, where password guessing, credential stuffing and password reuse are routine entry paths. In Azure, the practical goal is to make interactive sign-in harder to abuse and easier to govern.

Key-based authentication also changes the failure mode. A password can be guessed, reused or phished once and then replayed broadly; a private key is harder to steal at scale and is less exposed to automated brute-force campaigns. For that reason, password authentication should be disabled wherever the workload and access model allow it, not treated as a backup option.

Azure guidance around SSH access pairs naturally with broader key hygiene. Use a controlled process for generating, distributing, rotating and removing keys, and treat orphaned entries in authorized_keys as standing access that can outlive the original owner. NHIMG’s SSH Key and SSH Certificate Management Guide is useful for the lifecycle side of that problem, especially where sprawl and stale access become the real risk.

Where password authentication fails in practice

Password logins fail first on predictability. Even a strong password policy does not stop stolen credentials from being reused, and remote admin interfaces are frequent targets for automated login attempts. If an operator ever copies the same password into another service, an unrelated compromise can become the entry point to a VM.

They also fail on visibility. A valid password tells you little about whether the login was intended, shared, exposed or silently harvested. By contrast, SSH key usage can be paired with better account review, host-level logging and tighter control over which principals are allowed to authenticate. That is why password authentication is not just weaker, it is harder to govern at scale.

When keys are managed badly, the problem shifts rather than disappears. Leaked private keys, overbroad authorized_keys files and long-lived access entries can still create durable compromise paths. NHIMG’s Secrets in Docker Hub images (RWTH Aachen study) shows how exposed key material can persist far beyond the original leak, which is why key storage and rotation discipline matter as much as the choice of authentication method.

Real-world compromises also show how valid credentials enable lateral movement once an attacker has any usable remote access path. NHIMG’s SonicWall SSL VPN account compromises 2025 is a reminder that authenticated access, not just malware, can be enough to enter and expand inside an environment.

How to implement SSH keys without creating a new trust problem

Key-based login is only an improvement if the surrounding controls are disciplined. Prefer per-user or per-service keys, remove shared keys, and make rotation and offboarding part of the normal access lifecycle rather than an incident response task. If you allow a fallback password path, treat it as a temporary exception with an expiry, not a permanent convenience feature.

Also verify the management plane. Ensure cloud access policy, local SSH configuration and OS account state all align, because a secure Azure setting can be undermined by a permissive image, a copied admin account or an inherited authorized_keys file. The operational question is not whether SSH keys are used somewhere, but whether every surviving key is still owned, needed and reviewable.

For rollout patterns, the safest sequence is to provision keys first, confirm console or break-glass access second, then disable password authentication only after you have verified that no automation, support account or legacy script still depends on interactive password entry. That sequencing avoids lockout while still removing the reusable secret from routine remote access.

Risk and Threat Considerations

Password-based SSH invites brute force, credential stuffing and password reuse abuse, especially on exposed Linux VMs. The main exposure is not only account takeover, but also the ease with which a single stolen password can be replayed across multiple systems if access is not tightly segmented.

Failure mechanism: An attacker guesses, reuses or harvests a password, then authenticates remotely and uses the live session to pivot, modify accounts or plant persistence. Because the login is valid, the activity can look like ordinary administration unless logging and alerting are tuned to detect unusual source addresses, account changes or new key insertion.

Impact: A compromised VM can become a foothold for privilege escalation, data exposure or broader lateral movement, and password reuse can widen the blast radius well beyond the first host.

Practitioner Guidance

What to verify: Confirm that password authentication is disabled on every internet-reachable Linux VM unless a documented exception exists. Also verify that each authorized key maps to a current owner, current purpose and current environment, because stale keys are the most common hidden exception.

Decision rule: If an account can reach a production VM from the network, treat key rotation and password removal as a baseline control, not an optional hardening step. If you must keep a password path, make it temporary, monitored and explicitly approved.

Practitioner takeaway: SSH keys are safer than passwords because they reduce reusable secret exposure, but the real control objective is to govern the full key lifecycle and eliminate leftover access paths before they become standing remote access.

Related resources from NHI Mgmt Group

• When should organisations use identity-based authentication instead of API keys for Azure OpenAI access?
• Should organisations use SSH certificates instead of long-lived keys?
• Why does password protecting SSH keys still matter even when teams use an SSH agent?
• What happens when organisations use ephemeral certificates instead of SSH keys for privileged sessions?