Intermittent SSH Authentication unsuccessful

[apkg]

Hi All,

I am running the Community Containers in Docker rootless on Ubuntu 24 LTS but am having an issue with the scanner intermittently failing to authenticate SSH connections.

I am authenticating with username+keypair, which I’ve confirmed works between the Ubuntu host machine and scanned host, and independently of the Greenbone setup. From one scheduled scan to the next, I am seeing different hosts report not being able authenticate an SSH connection. For example; one day host1.example.com will work fine, the next day it will fail. I’ve checked the ssh logs on the scanned host when it fails, and it says the peer closed the session.

To prove whether this was the environment running the containers or our hosts/network, I setup a Kali Linux 2025.2 virtual server and installed Greenbone from it’s native repos. Running a System Discovery scan returned a 100% success rate for authenticated SSH sessions, using the same hosts and keypair. On the Ubuntu24/docker setup, its usually about 50% but have seen it as low as 15%! So I know it’s not our hosts, the keypair, our network or hypervisor setup.

It looks to be something to do with running Greenbone in docker on Ubuntu 24 LTS. The docker host OS is fully up-to-date, I’m running the latest container images, and using the latest version of the docker-compose.yml from the Community documentation page.

We do not want to go down the route of just using the Kali host, and would like to continue using the Ubuntu 24 LTS docker setup. So any help would be greatly appreciated.

Many thanks,

APKG

[Eero]

@apkg its probably related to ssh library versions that are installed in “scan host”. not sure which python library ssh connection uses in openvas.

Eero

[rippledj (Joseph)]

Just to clarify, openvas-scanner SSH connections for authenticated scans are implemented in nasl_ssh.c, not Python.

Can you find any indicators in the log files? Inspecting nasl_ssh.c shows that most of the process includes logging. You may have to enable log_whole_attack in the /etc/openvas/openvas.conf configuration file.

Sounds like resource exhaustion on the client side, but without seeing the logs or knowing the network environment .

[cfi]

@rippledj

You may have to enable log_whole_attack in the /etc/openvas/openvas.conf configuration file.

For clarification, log_whole_attack is only enabling logging of executed VTs (e.g. which are getting started and the like) but doesn’t include any SSH authenticated info or similar. There is a dedicated scanner relevant configuration which is documented by the scanner team here.

[rippledj (Joseph)]

There is a dedicated scanner relevant config

Yes my mistake, enabling the NASL ssh connection logs would require setting level=128 in the openvas_log.conf file.