Non-Standard SSH string SSH-0.12

Scanning / scan configuration
1

OpenVAS fails to perform authenticated SSH scanning of UniFi Access Points. Credentials are configured correctly and manual SSH works fine from the same server. I discovered that OpenVAS sends a non-standard SSH protocol identifier SSH-0.12-OpenVASVTSSH_1.0 which Dropbear correctly rejects as incompatible. The UniFi AP logs show: Exit before auth from <scanner_ip>: Incompatible remote version 'SSH-0.12-OpenVASVTSSH_1.0'. The AP advertises standard SSH-2.0-dropbear_2024.86 and accepts connections from standard SSH clients. Is the SSH-0.12-OpenVASVTSSH_1.0 identifier intentional, and if so, what’s its purpose. Is there any way to configure OpenVAS to use standard SSH-2.0 protocol for better compatibility? Has this Dropbear incompatibility been reported before, and are there any workarounds?

2

This is the intended behavior of the VT ssh_proto_version.nasl with OID 1.3.6.1.4.1.25623.1.0.100259. This does not mean that all SSH traffic is being rejected or that SSH authenticated checks are failing. OpenVAS is will detects whether DropBear is in use.

The despiction reads:

# Versions of SSH protcol to test are set:
versions = make_list( "0.12", "1.33", "1.5", "1.99", "2.0" );

Depending on your SSH server config, you may see log results like:

Also, you will see a log listing the SSH protcol versions that your server accepts:

Please enable logs on the scan results and read them carefully.

1 Like
3

Hello,

and welcome to this community forums.

I can confirm what has been written previously, the SSH-0.12-OpenVASVTSSH_1.0 is expected / by design for remote unauthenticated service probes. It can’t be changed and is also not relevant / related to any authenticated scanning.

For authenticated scanning the scanner is using the underlying https://www.libssh.org/ library which is using a default / standard SSH protocol identifier.

Why an authentication fails depends on a lot of environmental factors like e.g.:

  1. The used libssh version on the scanner host (older or newer versions might have bugs or incompatibilities which could cause a failed login)
  2. Incompatible algorithms between the server (Dropbear) and the client (Scanner/libssh). For example the target host might only support specific algorithms which are not supported by libssh anymore, especially hardening done by the Linux distribution about cipher usage might play a role here as well
  3. Some unsupported configuration on the server (Dropbear) side like mentioned on e.g. OPENVAS SCAN Manual: 9.3.5 Requirements on Target Systems with Linux/Unix
  4. Probably a lot more

Unfortunately the scanner doesn’t provide any user/NASL facing logging for debugging authentication failures so the only chance left to determine why the authentication fails is to investigate the logs on the target system for any hints on these.

4

I will review the logs thank you. At this point the only problem I have is OpenVAS cannot perform authenticated SSH scanning of Ubiquiti UniFi Access Points due to SSH protocol version incompatibility. The OpenVAS scanner sends a non-standard SSH protocol identifier (`SSH-0.12-OpenVASVTSSH_1.0`) that Dropbear SSH servers correctly reject as incompatible with SSH-2.0 standard. All other SSH has connecxted successfully

5

I’ll try to make this clear to you again: OpenVAS sends a standard SSH protocol version string when doing SSH authenticated scans. There must be some other problem with your authenticated scans of the Ubiquiti UniFi but it is not because OpenVAS is sending the SSH-0.12-OpenVASVTSSH_1.0 protocol version string. That string is only sent ONCE for a special remote vulnerability test of the target system - NOT for authenticated scans.

See the screenshot. It is all traffic from the OPENVAS SCAN. The authenticated tests are all sending the standard SSH-2.0- libssh_0.10.6 protocol version string.

ssh-version-ids-ssh-2.0
ssh-version-ids-ssh-2.0573Ă—380 17.4 KB

1 Like
6

Thank you again, my comment was to only add that all other ssh works fine for me. I can see what I added was confusing

7

“all other ssh” is most likely using OpenSSH while the scanner is using libssh. So the biggest difference might be the use of the SSH implementation concerning e.g. algorithms, bugs and similar so comparing both (even from the same system) probably won’t help much to determine where the login problems are originating from.

And the goal of @rippledj was probably to point out that this statement is not correct:

OpenVAS cannot perform authenticated SSH scanning of Ubiquiti UniFi Access Points due to SSH protocol version incompatibility

because the SSH-0.12-OpenVASVTSSH_1.0 SSH protocol version identifier is actually not the culprit because it is just not used for authenticated scanning (as outlined previously).

1 Like