Hi guys,
I'm having an issue with Unimus on our Aruba CX switches. Unimus is working fine, backups are working, but the logs on these switches are filled with this:
2026-01-16T06:01:15.678768+01:00 USASJNC227-0-1-02 log-proxyd[775]: Event|5214|LOG_WARN|CDTR|1|SSH session from 10.8.5.45 denied due to host key verification failure.
I'm not sure what is the cause, I tried removing the host saved key with "ssh known-host remove" but I'm still getting the same error each time Unimus tries to connect to the switch. Two seconds after this log Unimus succesfuly connects to the switch:
2026-01-16 T 06:01:39.428741+01:00 log-proxyd[775]: Event|5211|LOG_INFO|CDTR|1|User unimus logged out of SSH session from 10.8.5.45.
2026-01-16 T 06:01:17.428867+01:00 log-proxyd[775]: Event|5209|LOG_INFO|CDTR|1|User unimus logged in from 10.8.5.45 through SSH session.
2026-01-16 T 06:01:15.678768+01:00 log-proxyd[775]: Event|5214|LOG_WARN|CDTR|1|SSH session from 10.8.5.45 denied due to host key verification failure.
Does anyone know what could be causing this behavior?
Also, I noticed that every time my Unimus backup starts (every 6 hours), two connection attempts happen on each switch with a minute apart from eachother (you can see this in the logs above). This happens on both the new CX and old 2930 Arubas.
I have double checked my scheduled tasks in Unimus and the only one I have is the backup which runs every 6 hours, so I don't understand why are there two connections to it?
This wouldn't be such an issue if I didn't also receive the SSH errors every time a connection happens, with that my switch logs are almost impossible to look at without filtering.
Aruba - SSH host key verification failure
I am not 100% on the SSH session host key issue, I will have to bug one of the guys who's more familiar with that system to give his input.
BUT!!! I can help you with the second issue you are seeing. (Unimus has 2 connection attempts)
When Unimus performs a Scheduled backup it does a Discovery first to make certain that the device is still what Unimus thinks it is. Basically it's a safety feature for situations where you replaced a device with another product type or vendor and didn't update Unimus before the scheduled backup.
https://wiki.unimus.net/display/UNPUB/D ... ledbackups
I will bug the guys and see who can help you with the SSH errors.
BUT!!! I can help you with the second issue you are seeing. (Unimus has 2 connection attempts)
When Unimus performs a Scheduled backup it does a Discovery first to make certain that the device is still what Unimus thinks it is. Basically it's a safety feature for situations where you replaced a device with another product type or vendor and didn't update Unimus before the scheduled backup.
https://wiki.unimus.net/display/UNPUB/D ... ledbackups
I will bug the guys and see who can help you with the SSH errors.
Okay, have gotten some feedback about how Unimus works and we have a few thoughts.
Prior to Unimus performing a Discovery or Backup Job, Unimus does a service check for the configured SSH port. Unimus opens only a TCP connection to the device. During this check, Unimus expects to receive the SSH server version string and then closes the connection immediately after it is received. On some devices we have observed log messages such as "Did not receive identification string" or "Failed in version exchange" as a result of this behavior.
We can attempt to replicate this behavior and verify this suspicion:
(Note, if you are running Windows, you can replicate this with PacketSender Portable, let me know if you would like more details.
If you see the log message repeated on your Aruba when you perform this action then we know this is the source of the log messages.
Prior to Unimus performing a Discovery or Backup Job, Unimus does a service check for the configured SSH port. Unimus opens only a TCP connection to the device. During this check, Unimus expects to receive the SSH server version string and then closes the connection immediately after it is received. On some devices we have observed log messages such as "Did not receive identification string" or "Failed in version exchange" as a result of this behavior.
We can attempt to replicate this behavior and verify this suspicion:
Code: Select all
apt intall netcat
netcat -v <your.router.ip.here> <SSH Port>
Connection to your.router.ip.here port [tcp/*] succeeded!
SSH-2.0-OpenSSH_9.3
^C <- CTRL+C pressed here
If you see the log message repeated on your Aruba when you perform this action then we know this is the source of the log messages.
Hi Tommy,
yes, I have just done the test commands and the same SSH host key verification failure message can be seen in the switch logs, so that is most likely the issue.
Thank you for the explanation and help, I guess we will just have to get used to it.
yes, I have just done the test commands and the same SSH host key verification failure message can be seen in the switch logs, so that is most likely the issue.
Thank you for the explanation and help, I guess we will just have to get used to it.
There may be a way to filter out those messages from being saved to memory.
I came across these from some quick searches.
https://arubanetworking.hpe.com/techdoc ... g%20filter
I know most other pieces of equipment I have worked with have exposes some kind of option to filter out specific log messages.
Sorry, I am not more familiar with the Aruba brand.
I came across these from some quick searches.
https://arubanetworking.hpe.com/techdoc ... g%20filter
I know most other pieces of equipment I have worked with have exposes some kind of option to filter out specific log messages.
Sorry, I am not more familiar with the Aruba brand.