Authentication to Linux machines should require SSH keys

What does the recommendation "Authentication to Linux machines should require SSH keys" check?

Uses the Azure Policy guest configuration extension to audit each Linux virtual machine and confirm that SSH password authentication is disabled, so logins can only use a public-private key pair. It inspects the in-guest sshd configuration rather than the VM resource definition, which means it catches drift where someone re-enabled passwords after deployment. The control is audit-only: it reports non-compliant machines but does not change sshd or block deployment. It does not evaluate Windows machines, does not cover Microsoft Entra ID login, and cannot run on a VM that lacks the guest configuration extension and a managed identity, so those machines simply show as not assessed rather than compliant.

Why does "Authentication to Linux machines should require SSH keys" matter?

A Linux host that still accepts SSH passwords is exposed to credential stuffing and brute-force attacks the moment port 22 is reachable, and internet-facing VMs are probed within minutes of coming online. One weak or reused password is enough to hand an attacker an interactive shell, and from there lateral movement, crypto-mining or data theft follow quickly. Key-based authentication removes the guessable secret entirely: there is nothing to brute-force, so an entire class of automated attack stops working. For a regulated organisation, a single password-authenticated server is also the kind of finding that fails an audit and forces remediation under deadline.

How do I fix "Authentication to Linux machines should require SSH keys"?

1. On each flagged VM, edit /etc/ssh/sshd_config to set 'PasswordAuthentication no', reload sshd, and confirm your key-based login works before closing the session so you do not lock yourself out.
2. Build new Linux VMs key-only from the start: with the CLI use 'az vm create --authentication-type ssh' together with '--ssh-key-values <path-to-public-key.pub>' (or '--generate-ssh-keys'), which sets disablePasswordAuthentication to true. In Bicep or ARM, set osProfile.linuxConfiguration.disablePasswordAuthentication to true and supply a publicKeys entry.
3. Assign the built-in policy so future drift is caught automatically, looking the definition up by name rather than hardcoding a GUID: pid=$(az policy definition list --query "[?displayName=='Authentication to Linux machines should require SSH keys'].name" -o tsv); az policy assignment create --name require-ssh-keys --policy "$pid" --scope <scope>. Make sure target VMs have the guest configuration extension and a system-assigned managed identity so the audit can actually evaluate them.

# 1. Establish the Entra path FIRST: provision a SQL Entra admin (an Entra group is best).
gid=$(az ad group show --group "sql-admins" --query id -o tsv)
az sql server ad-admin create \
  --resource-group rg-data \
  --server-name sqlprodcust \
  --display-name "sql-admins" \
  --object-id "$gid"

# 2. Switch the Synapse workspace to Microsoft Entra ID Only (local SQL admin disabled).
az synapse workspace update \
  --resource-group rg-data \
  --name synprodanalytics \
  --use-microsoft-entra-only-authentication true

# 3. Disable the Cosmos DB account key ONLY after clients use a managed identity (NoSQL API).
az resource update \
  --resource-group rg-data \
  --name cosmosprodcust \
  --resource-type "Microsoft.DocumentDB/databaseAccounts" \
  --set properties.disableLocalAuth=true

# 4. Ratchet it shut: assign the built-in policy by its EXACT display name (look up its id, never hardcode a GUID).
pid=$(az policy definition list \
  --query "[?displayName=='An Azure Active Directory administrator should be provisioned for SQL servers'].name" -o tsv)
az policy assignment create \
  --name require-sql-entra-admin \
  --policy "$pid" \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000"