2

We recently bought the sg350-28 28 port Gigabit Managed Switch

I need be able to run Credentialed nessus scans on these devices

SSH is enabled

I can SSH from putty

I can SSH from the sever where nessus is installed

I can also SSH into the devices from other devices such as routers.

I have checked and nessus will do a Credentialed scan against other ssh devices, (RHEL 7)

Any idea why this is not working?

The user I am using is setup as level 15

username aftest

password Test1234 (really simple)

I created a user that can only log in via key, same thing.

enter image description here

I have followed the Nessus article

https://community.tenable.com/s/article/Authentication-Requirements-for-Credentialed-Cisco-Scans

enter image description here

Another thing I have noticed is that it looks like Nessus is not trying to ssh into the switch

enter image description here

On the left is the output of the logs from the switch, when I ssh in from the server running nessus I can see that ssh connections was accepted

However, when I started the scan, no logs at all. No login attempts

Not sure if any other logs might be helpful

Wireshark info, not sure what is important, however looking at the scan I can see that Nessus is trying to do something on port 22

enter image description here

Red bar output

enter image description here

Black bar output

enter image description here

nessussg350.pcapng

https://file.io/sQrmRAj7Psrj

104410 None 172.16.1.14 tcp 22 Target Credential Status by Authentication Protocol - Failure for Provided Credentials "Nessus was unable to log into the detected authentication protocol, using the provided credentials, in order to perform credentialed checks." "Nessus failed to successfully authenticate directly to the remote target on an available authentication protocol. Nessus was able to connect to the remote port and identify that the service running on the port supports an authentication protocol, but Nessus failed to authenticate to the remote service using the provided credentials.

There may have been a failure in protocol negotiation or communication that prevented authentication from being attempted or all of the provided credentials for the authentication protocol may have been invalid. A protocol failure may indicate a compatibility issue with the protocol configuration. A protocol failure due to an environmental issue such as resource or congestion issues may also prevent valid credentials from being identified. See plugin output for error details.

Please note the following :

  • This plugin reports per protocol, so it is possible for valid credentials to be provided for one protocol and not another. For example, authentication may succeed via SSH but fail via SMB, while no credentials were provided for an available SNMP service.

  • Providing valid credentials for all available authentication protocols may improve scan coverage, but the value of successful authentication for a given protocol may vary from target to target depending upon what data (if any) is gathered from the target via that protocol. For example, successful authentication via SSH is more valuable for Linux targets than for Windows targets, and likewise successful authentication via SMB is more valuable for Windows targets than for Linux targets." "Address the reported problem(s) so that credentialed checks can be executed." " Nessus was unable to log into the following host for which credentials have been provided :

    Protocol : SSH Port : 22 Failure details :

    • User : aftest

      • Plugin : netstat_portscan.nasl Plugin ID : 14272 Plugin Name : Netstat Portscanner (SSH) Message : ssh_recv failed in ssh_kex2.

      • Plugin : ssh_get_info.nasl Plugin ID : 12634 Plugin Name : Authenticated Check : OS Name and Installed Package Enumeration Message : ssh_recv failed in ssh_kex2. "

11
  • Is the switch returning some unexpected banner or prompt, causing Nessus to think it failed to authenticate?
    – Ron Trunk
    Feb 14 at 20:56
  • @RonTrunk No I do think so, when I connect via ssh from the server running nessus what you see is in the screen shot above. What I would expect to see if Nessus is trying to create an SSH session either pass or fail a message saying so, however I do not see nessus even trying to create the SSH session. I know something is working as will give output about the system, os version, mac address, etc, so I know it is connecting. Feb 14 at 21:35
  • @JamesConnigan I'd run a packet trace to see if there's anything going on or not.
    – Zac67
    Feb 14 at 21:46
  • 1
    It's not showing much detail, but it looks like the client SSH handshake doesn't work. Have you tried a plainer SSHv2 login? In any case, Nessus should log what it tries to do and what doesn't work out.
    – Zac67
    Feb 14 at 22:12
  • 2
    It looks a lot to me like incompatibility between OpenSSH versions (5 vs 7) and maybe the encryption the older switch chooses to use, which might not be strong enough to be approved by the other host. This is just a thought, but I've seen problems like this before.
    – user56700
    Feb 18 at 12:49

1 Answer 1

2
+50

I've used a !arp && !dhcp && !stp && !cdp && !ssdp && !lldp display filter - I prefer filtering away what I don't want instead of just displaying what I want (tcp.port == 22) which could hide unexpected data.

  • frame #57 contains the start of a TCP connection from 192.168.1.10 (assumed Nessus server) to 192.168.1.254 (assumed SG350)
  • #60 is the beginning SSH handshake (server/switch response SSH-2.0-OpenSSH_7.3p1.RL) )
  • #62 is the client/Nessus response SSH-2.0-OpenSSH_5.0
  • the switch is slow with its ACK (#62 is retransmitted in #63)
  • eventually ACKs in #64
  • and then kills the connection in #102 (possible timeout)

That pattern repeats several times.

In a normal SSH connection, the client would initate the key exchange after #64. I'd say the Nessus software is at fault for failing to do that in time. It may be due to the switch generally missing the first ACK but that mustn't be a problem for a client.

3
  • This. We're having the very similar effects when trying to SSH into latest firmware SG350 series switches from our (slightly outdated version of ) KiwiCat Tools. Packet dumping revelas that key exchange fails, but all log entries we find are vague and hint at a connectivity problem - which is actually isn't. Feb 18 at 22:09
  • @Marc'netztier'Luethi Wild guess but possibly they're using the exact same piece of code.
    – Zac67
    Feb 19 at 17:20
  • It wouldn't be the first time Cisco make mistakes like this, unfortunately. It also took them way too long to update and remove the SHA1 key exchange from their older software and switches.
    – user56700
    Feb 22 at 9:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.