Oxidized failing to auto ssh to Panorama

[CootieCooter]

Hey all,

On December 18, our Oxidized has not pulled the config from Panorama, and has not alerted us via emails or shown on Oxidized Web of any config changes made on Panorama and its firewalls. This has worked before then, so unsure what could have happened since we don't really tamper with any Oxidized stuff unless something goes wrong. I did open a palo alto case to see if its something on the Panorama side, but want to cover both sides of any possibilities.

From the oxidized server, and with attempts made as the oxidized user (logged in as the local oxi user as well as did ssh oxidized@ from a personal admin account), I have been able to successfully ping and manually ssh to our Panorama. However, in the oxidized logs, we see this:

W, [2025-01-29T21:33:40.903375 #2862817]  WARN -- : panos/<panorama> status no_connection, retries exhausted, giving up
W, [2025-01-29T21:41:00.509908 #2862817]  WARN -- : panos/<panorama> status no_connection, retry attempt 1
W, [2025-01-29T21:41:02.514513 #2862817]  WARN -- : panos/<panorama> status no_connection, retry attempt 2
W, [2025-01-29T21:41:04.518270 #2862817]  WARN -- : panos/<panorama> status no_connection, retry attempt 3

Confused on how to troubleshoot this exactly given that our Panorama doesn't show traffic to itself, but only to its firewalls, which our Oxidized is not connecting to.
I have made the config changes afterwards but only to set debug to true and by increasing the time out interval. However, I have not restarted the Oxidized service to have these changes take effect because with our luck and history, every time we restart oxidized, something goes wrong like it failing to start or something with the node list or something else. Overall, we try to not restart it ever given the uncertainty of trouble that can follow. Plus, Oxidized is working as intended for our other 100+ devices, so I do not want to break/stop everything just to get 1 machine to work, so hoping we can figure this out without tampering with the running service if possible. Maybe a way to have Oxidized re-fetch its config file without the running service be too disrupted?

I can provide more info on any other questions if asked, so please let me know!
Thank you to all who take the time to read this and provide any kind of feedback!

[CootieCooter]

Some more errors/output that I found regarding our issue. We thought maybe the local oxidized account on the Panorama was locked, so we changed the password there as well as in the models + group section of the oxidized config file, but still ran into same issues. Also restarted oxidized service multiple times but no resolution. -->

D, [2025-02-05T16:53:04.760073 #1868203] DEBUG -- : raised Net::SSH::Disconnect with msg "disconnected: Too many authentication failures (2)"
D, [2025-02-05T16:53:07.488008 #1868203] DEBUG -- : raised Net::SSH::Disconnect with msg "disconnected: Too many authentication failures (2)"

2025/01/30 22:08:59 2025/01/30 22:08:59 medium auth auth-fail 0 000710024522 failed authentication for user 'oxidized'. Reason: Invalid username/password. From: .
2025/01/30 22:09:03 2025/01/30 22:09:03 medium auth auth-fail 0 000710024522 failed authentication for user 'oxidized'. Reason: Invalid username/password. From: .
2025/01/30 22:10:09 2025/01/30 22:10:09 info auth auth-success 0 000710024522 authenticated for user 'oxidized'. From: .

Jan 30 00:30:50 sshd[17513]: Disconnecting authenticating user oxidized port 35724: Too many authentication failures [preauth]
userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]