The host was remediated against its host profile. The compliance check runs again and the host is still Non-compliant, for one item: "SSH public key not present in profile for root". Remediating again is the obvious move. On ESXi 8.0 it can leave the host exactly where it was, or leave the key in place but unusable for login.
This article records what differs between the profile and the host and matches it to the two documented ESXi 8.0 causes. The owners decide what happens next.
Scope
ESXi 8.0, a classic host profile, and the root SSH public key setting only. Every step is a read. Not covered: vSphere Configuration Profiles, other non-compliant settings, enabling SSH, and any change. ESXi patching has its own article: patch an ESXi cluster with vSphere Lifecycle Manager.
Public keys are not secrets, but a record does not need them. Record each key by its comment and fingerprint, never the key text.
What the compliance result means
The vSphere 8.0 guide says the check shows "if any configuration parameters on a host are different from those specified in the host profile", and that "A non-compliant status indicates a discovered and specific inconsistency between the profile and the host." The differing parameters are shown in the host profile's Monitor tab, Compliance view, after selecting the failing host.
Two ESXi 8.0 articles describe this exact item staying Non-compliant after remediation:
| Cause | What Broadcom says | Source |
|---|---|---|
| Key order | With several keys, the host and a compliant host have the same keys "but in a different order". Remediation changes the order, and "This change in the order of the keys also occurs when rebooting an ESXi host remediated with a host profile." | KB 421209 |
| Key option quoting | A key with a source restriction such as from="1.2.3.4" loses its double quotes when written to the host, because the profile engine is "not properly escaping the double quotes". The host stays non-compliant and "SSH login attempts using the key are failing". |
KB 326278 |
Step 1: record the compliance result
| Field | What to record |
|---|---|
| A | Host, ESXi version and build, vCenter version, host profile name |
| B | Time of the last remediation and of the last compliance check, with time zone; whether the host has rebooted since remediation |
| C | Every Non-compliant item the Compliance view shows for this host, with its exact text |
| D | Whether the root SSH key item is the only one |
Step 2: record the profile's key list
From Security and Services > Security Settings > Security > User Configuration > root in the host profile:
| Field | What to record |
|---|---|
| E | Number of keys, and for each in order: key type, comment, fingerprint |
| F | For each key, any option before the key type (for example a from= restriction), written exactly, including quotes or backslashes |
Step 3: record the host's key list
From /etc/ssh/keys-root/authorized_keys on the host, read by someone already authorised to read it:
| Field | What to record |
|---|---|
| G | Number of keys, and for each in order: key type, comment, fingerprint |
| H | For each key, its option text exactly as it appears in the file |
| I | Whether login with each restricted key is known to work or fail, from existing records only. Do not attempt a login for this record |
Step 4: classify
| What the record shows | Candidate cause | Handed to |
|---|---|---|
| E and G list the same keys, same count, different order | Key order (KB 421209). Broadcom says "There is currently no workaround for this issue." | vSphere owner |
F shows from="..." and H shows the same option without the double quotes |
Key option quoting (KB 326278); key-based login with that key is expected to fail | vSphere owner and whoever uses the key |
| E and G differ in count or fingerprints | A real key difference; not either documented cause | Security owner, then vSphere owner |
| C shows other items as well | Each item is its own question; this record covers the SSH key only | vSphere owner |
Both documented causes can apply at once. A match explains why the status did not clear; it does not say the keys on the host are the ones that should be there.
What this record does not authorise
The record ends when it is handed over. It does not authorise remediating again, rebooting, editing authorized_keys, reordering keys, adding or removing backslashes in the profile, adding or removing keys, enabling SSH, or disabling the setting in the profile. Both KB articles describe temporary steps; whether to use either is the owners' decision, under its own change record, because:
- the vSphere 8.0 guide says remediation updates "all host profile parameters" to the profile's values, not only the key, and some settings need a reboot and maintenance mode;
- a change to root's keys changes who can log in to the host.
Worked example (fictional)
The values below are invented. Host esx-14, ESXi 8.0 U3, profile prod-gold. Remediated 02:10 AEDT, rebooted 02:25, checked 08:00: Non-compliant, one item, "SSH public key not present in profile for root".
| Field | Value |
|---|---|
| E | 3 keys: ops-vault, backup-01, audit-ro; backup-01 has from="10.20.0.15" |
| G | 3 keys, same fingerprints, order audit-ro, ops-vault, backup-01 |
| H | backup-01 option reads from=10.20.0.15, no quotes |
| I | Backup team ticket from 03:00: key login from 10.20.0.15 refused |
Classification: both documented causes. Same keys in a different order (KB 421209), and the from= option lost its quotes, which matches the backup login failure (KB 326278). The record goes to the vSphere owner and the backup team. Nothing is changed.
Acceptance checks
- Fields A to I are recorded, or marked not available with the reason.
- No key text appears in the record, only type, comment and fingerprint.
- Quotes and backslashes in F and H are copied exactly.
- No login was attempted and nothing was remediated, rebooted or edited. Reading needs no rollback.
Learning notes
- Non-compliant means a specific difference was found; the Compliance view names it.
- On ESXi 8.0, two documented causes keep the root SSH key item Non-compliant after remediation: key order, and lost quotes around a
from=option. - The second cause also breaks login with that key, so it is more than a reporting issue.
- Remediating again changes every profile setting, not only the key.
Related articles
- Published: How to patch an ESXi cluster with vSphere Lifecycle Manager
- Published: How to harden VMware without breaking operations or recovery
Sources
Retrieved 2026-11-03 UTC (4 November, Australia/Sydney). Dates are each page's own Updated On or Last Updated date.
- Broadcom KB 421209, "Remediating an ESXi host using host profiles results in sshKey being non-compliant during compliance check", 29 January 2026. https://knowledge.broadcom.com/external/article/421209/remediating-an-esxi-host-using-host-prof.html
- Broadcom KB 326278, "Assigning an SSH public key to ESXi 8.0 using a host profile results in key-based SSH authentication failing", 21 December 2025. https://knowledge.broadcom.com/external/article/326278/assigning-an-ssh-public-key-to-esxi-80-u.html
- Broadcom TechDocs, vSphere 8.0, "How Do You Check Compliance of Hosts or Clusters to a vSphere Host Profile?", 28 October 2026. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/host-profiles/how-do-you-manage-host-profiles-in-the-vsphere-client/how-do-you-manage-compliance-checks-of-hosts-and-clusters-to-a-vsphere-host-profile/check-compliance.html
- Broadcom TechDocs, vSphere 8.0, "How Do You Remediate a Host to Comply with a vSphere Host Profile Configuration?", 28 October 2026. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/host-profiles/how-do-you-manage-host-profiles-in-the-vsphere-client/how-do-you-manage-compliance-checks-of-hosts-and-clusters-to-a-vsphere-host-profile/remediate-a-host.html