Version fingerprinting is mostly based on software version banners. In case of SSH, a server may answer with the following output upon a client connecting:
$ nc example.org 22
SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.6
This would be read as OpenSSH 8.9p1 by Qualys and thus deemed outdated and vulnerable against, e.g., CVE 2023-38408. In this case however, the vendor of the Linux distribution Ubuntu, Canonical, is responsible for shipping updates and uses a technique called Backporting to apply security fixes from more recent versions of OpenSSH to older ones. The idea is to keep the same feature set (and thus possibly prevent breakage due to changes) while providing a similar level of security.
The system may be configured to not display version information:
$ nc example.org 22
SSH-2.0-OpenSSH
This renders version fingerprinting through banners useless and since Qualys is a passive scanner, no aggressive other methods are employed. In this case, the package information must be retrieved locally and then the same steps executed.
<aside> 📌
In an ideal scenario, the current version of every deployed system is registered in an Asset DB with cross-referenced CVEs. Since this data is sourced internally, it is much more accurate and false positives such as the above won’t occur. It is still useful to double-check with external scanners occasionally to check whether there are systems that are not registered in the asset database.
</aside>
For Ubuntu, the above banner corresponds to the package openssh-1:8.9p1-3ubuntu0.6 . This reads as OpenSSH 8.9p1, but in the version openssh-1:8.9p1-3 as shipped by the Linux distribution Debian. The 3 indicates the third revision of said Debian package, possibly already including security backports. Since Ubuntu is itself based on Debian, the ubuntu0.6 indicates that 6 additional changes/revisions where made by Canonical on top of that. Unfortunately we are still not sure whether this version is the most recent or affected by CVE 2023-38408.
With access to the actual system, using the system’s package manager (apt, dnf/yum, zypper, …) to display the installed version is of course more accurate.
For Ubuntu, the CVE we can easily view however which packages are affected by visiting their respective security bulletin:
<https://ubuntu.com/security/CVE-2023-38408>
From there we can see that indeed, Ubuntu 22.04 LTS had this issue fixed in 1:8.9p1-3ubuntu0.3 — 3 versions below the one installed, thus we’re already good!
Similarly, for Debian, we can use a similar site:
<https://security-tracker.debian.org/tracker/CVE-2023-38408>
Analogs exist for other vendors (Red Hat, SUSE, Microsoft Windows) to consult in this case. Unfortunately, the case isn’t always as clear.