A Nessus credentialed scan of Linux servers returned far fewer findings than expected — which Nessus plugins and settings show whether the credentials actually worked?
answer
- the scan's own information plugin
- Credentialed checks : yes needs more
- a plugin that is silent on success
- Credential Validation template
- least privilege plugins 102094, 102095
basics
~10 sRead plugin 19506 (Nessus Scan Information): on Linux, Credentialed checks : yes needs a login and a retrieved package inventory. Plugin 21745 reports failed SSH or Windows logins but is silent on success.
solid answer
~40 sStart with plugin **19506** (Nessus Scan Information) for each host. On Linux, Unix and macOS, `Credentialed checks : yes` requires both a successful login and retrieval of the OS-native package inventory (rpm, dpkg and so on), so authentication alone is not enough. Then look for plugin **21745**, which reports when SSH or Windows credentials did not let the scan log in; it produces nothing when the login succeeds, so its absence only means something if it ran. To test credentials without a full scan, use the `Credential Validation` template. If you enabled `Attempt least privilege`, plugins **102094** and **102095** list the SSH commands that needed, or ran with, privilege escalation. Also check `Automatically accept detected SSH disclaimer prompts`: when it is disabled, hosts that show a login banner prompt fail credentialed checks.
go deeper
Recall that plugin 19506 summarises each host's scan and shows whether credentialed checks ran.
Explain what 19506's yes requires on Linux and Windows, and why 21745 is only evidence when it actually ran.
Work a thin credentialed scan in order: 19506, 21745, disclaimer prompts and SSH settings, then 102094 for missing privileges.
Treat credential health as a monitored signal across every scan, not a per-scan check, and own the trade-off between privileged scan accounts and coverage.
## The situation A credentialed Nessus scan of a Linux fleet comes back with a fraction of the findings the team expected. The scan did not crash and no host is marked unreachable. Whether credentials matter is a general scanning question; this one is about the Nessus-specific evidence that tells you whether Nessus logged in and did its local checks. ## Plugin 19506: Nessus Scan Information Plugin **19506** (Nessus Scan Information) reports, for each scanned host, how the scan ran. Its `Credentialed checks` line is the first thing to read. The Nessus 10.12 guide sets a high bar for `Credentialed checks : yes`: - on **Linux, Unix and macOS**, it requires a successful credentialed login **and** successful retrieval of the OS-native package or patch inventory (for example `rpm`, `dpkg`, `lslpp`, `swlist`, `pkg`, `pkgutil`); - on **Windows**, it additionally requires remote registry enumeration and access to the system-drive administrative share, or SMB privileges sufficient for Microsoft security-bulletin checks; - **authentication success alone is not sufficient on any platform.** For network devices and APIs, 19506 reports the credential status in platform-specific forms, such as `Credentialed checks : yes as <user> via ssh` for SSH-reachable appliances, or `yes, via HTTPS` for API integrations. ## Plugin 21745: failures only Plugin **21745** detects whether SSH or Windows credentials failed to let the scan log in to the remote host. **When a login succeeds, it produces no result.** Two consequences: 1. A 21745 result on a host is direct evidence of a failed login there. 2. No 21745 result proves nothing unless the plugin was in the scan. A hand-picked limited-plugin policy may simply not include it. ## Settings that quietly break credentialed checks | Setting (Nessus 10.12) | Default | Why it matters | |---|---|---| | `Automatically accept detected SSH disclaimer prompts` | Disabled | Hosts that show a disclaimer prompt fail credentialed checks; the error appears in plugin output | | `Attempt least privilege` (SSH) | Cleared | When enabled, runs commands unprivileged first and escalates on failure; may add up to 30% to scan time | | `known_hosts file` (SSH) | none | If provided, Nessus attempts logins to the hosts in that file, guarding the audit account against hosts outside your control | | `Preferred port` (SSH) | 22 | A service on another port needs this changed | The guide also notes that Nessus opens several concurrent authenticated connections, so a strict account-lockout policy based on concurrent sessions can lock the scan account mid-scan. ## Account privilege by platform The guide is specific about what a credentialed scan account needs. On Linux, a non-privileged account can determine basic issues such as patch levels or entries in `/etc/passwd`, but system configuration data and file permissions across the whole system need **root** privileges, usually reached with an `Elevate privileges with` method such as sudo. On Windows, Nessus needs a **local administrator** account, because reading the registry alone is unreliable for patch level and Nessus needs direct file-system access to determine the true patch level. ## Diagnosing privilege, not just login A login can succeed while the account still lacks the rights local checks need. With `Attempt least privilege` enabled: - plugin **102094** (SSH Commands Require Privilege Escalation) lists commands that failed without escalation; - plugin **102095** (SSH Commands Ran With Privilege Escalation) lists commands that ran with it. Tenable's least-privilege procedure uses 102094's list to grant the scan account the permissions it needs, rescanning until 102094 reports no failed commands. Plugins **100158** (SSH Combined Host Command Logging) and **84239** (Debugging Log Report) go deeper but need plugin debugging enabled. ## Testing credentials before the real scan The `Credential Validation` template is a lightweight scan that verifies Windows and Unix credential pairs authenticate to the targets. Run it against a sample of the fleet after any credential change and before a long credentialed scan. When a scan carries many SSH credentials (up to 1,000, with Tenable recommending no more than 10), `Targets to Prioritize Credentials` tries the credential you know works on given IPs or CIDR blocks first. ## A working order 1. Read 19506 on several thin hosts: is `Credentialed checks` yes or no? 2. Look for 21745 results, after confirming the plugin was in the policy. 3. Check disclaimer prompts, `known_hosts` and the SSH port. 4. With least privilege on, use 102094 to find the commands the account cannot run. 5. Re-run `Credential Validation` before the next full scan.
- Plugin 19506 in a Nessus scan shows that SSH login worked, yet Credentialed checks is not yes on a Linux host. How is that possible?On Linux, Unix and macOS, `Credentialed checks : yes` also requires Nessus to retrieve the OS-native package inventory. An account that logs in but cannot run the package query, for example because privilege escalation failed, gives a login without credentialed checks. With `Attempt least privilege` enabled, plugin 102094 lists the commands that failed.
- Why does a hardened Linux host with a login banner fail Nessus credentialed checks while its neighbours pass?When `Automatically accept detected SSH disclaimer prompts` is disabled, which is the default, Nessus cannot get past a disclaimer prompt, so the credentialed scan fails on that host and the error appears in the plugin output. Enable the setting for hosts that present such prompts.
saying these in an interview costs you the question
- If plugin 21745 is absent, the credentials definitely worked on every host.
- Credentialed checks : yes in plugin 19506 only means the SSH login succeeded.
- Nessus answers SSH disclaimer prompts automatically by default.
- Attempt least privilege is enabled by default and costs nothing in scan time.
- A successful login proves the scan account had every privilege local checks need.