Scanner can't login successfully by SSH to random servers

[chushev]

We have about 30…40 servers in the local network, I can connect by SSH using my key to all of them (tested million times).
I’ve put my private SSH key to the greenbone credentials and scanning all servers.
Only about 5…10 servers getting “SSH Login Successful For Authenticated Checks” and “SSH Authorization Check” and servers list looks completely random!
How I can realize why some servers can be connected and some doesnt??

My initial tred was here:

Auth column in the /reports/hosts table

I’m scanning bunch of servers by the mask (like 192.168.0.0/16) and getting a report. On the column “Auth” some servers has a mark of successful ssh authentication, some hasn’t, but not a mark of unsuccessful auth (I saw this mark before, so there are 3 states of auth status: yes, no and nothing). I’ve checked /var/log/auth.log on my servers, and they looks similar, I see that scanner was connected by ssh. So why the difference in auth status?

[rippledj]

My first guess is that the Greenbone host’s ssh_config file is configured differently in the ssh_config file on the target host. If the target host’s ssh_config file does not enable at least one of the cipher algorithm suites suppored by SSH on the Greenbone host, for initializing connection and ongoing connection, the connection will fail.

[rippledj]

If this is indeed the issue, or otherwise, you should find detailed explanation for why the SSH connection failed in the logs of the scan task report. You need to enable logs to see these items. For example:

SSH Protocol Algorithms Supported
	
Wed, Mar 6, 2024 8:10 AM UTC
Summary
This script detects which algorithms are supported by the remote
  SSH service.
Detection Result

The following options are supported by the remote SSH service:

kex_algorithms:
curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

server_host_key_algorithms:
ecdsa-sha2-nistp256,ssh-ed25519

encryption_algorithms_client_to_server:
aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc

encryption_algorithms_server_to_client:
aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc

mac_algorithms_client_to_server:
umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1

mac_algorithms_server_to_client:
umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1

compression_algorithms_client_to_server:
none,zlib@openssh.com

compression_algorithms_server_to_client:
none,zlib@openssh.com

[chushev]

Thank you for answers, we finally find out the solution!
Problem was here: We changed plugin_timeout, set it too low!