ServiceNow Discovery: SSH credentials work initially, then stop working later

[MarxA]

ServiceNow Discovery: SSH credentials work initially, then stop working later (credentials appear to be cleared/overwritten)

Hi everyone,
I’m looking for outside ideas on an intermittent Discovery issue.

Context:

• Environment includes Avaya/telephony devices and Linux servers.
• Discovery works at first, and targets are discovered successfully.
• After some time, Discovery can no longer authenticate over SSH.
• In some cases, it looks like the SSH credential mapping/reference is no longer usable (for example, empty credential reference at runtime).
• SNMP may still run, but SSH authentication path does not continue.

Observed behavior:

• Re-adding the SSH key or recreating the discovery user restores discovery temporarily.
• Later, the problem comes back.
• This suggests something is changing after initial success (automation/policy/sync/rotation?).

What we already checked:

• SSH port is reachable.
• Manual server-side key files/permissions looked correct at check time.
• No obvious manual deletion process identified on our team side.
• We suspect an automated process may be overwriting/removing credential data over time.

Questions:

1. Has anyone seen Discovery credentials (especially SSH key-based) become invalid after initial successful runs?
2. What are the most common root causes in ServiceNow for this pattern?
3. Which logs/tables are best to prove what changed the credential reference (audit, scheduled jobs, integrations, MID activity)?

Any pointers, known defects, or troubleshooting checklists would be appreciated.

Thanks!

[Tanushree Maiti]

Hi  @MarxA 

Probable cause could be -

1. Private keys must be in OpenSSH format rather than Putty’s default .ppk format.

2.  the MID server might try to use outdated cached credentials.

3. If the MID server is upgraded, it may no longer support older algorithms . If the key uses an old algorithm, it will fail.

Refer following post for solution :

 https://www.servicenow.com/community/itom-forum/discovery-credentials-ssh-private-key/m-p/949068#:~:....

[MarxA]

Thanks, this is helpful.

We validated most of those points as well (key format, MID mapping, and account setup), but our issue appears to be more specific:

• It only affects a subset of Avaya/telephony devices and related servers.
• Other Linux/server groups using the same Discovery + MID setup remain stable.
• Initial discovery works, then later SSH auth fails until we re-add the key or recreate the service account.

So this looks less like a global PEM/PPK setup problem and more like a post-discovery drift on that Avaya subset (credential overwrite, account reset, key/policy sync, or automation on endpoint side).

If anyone has seen this specifically with Avaya environments, I’d appreciate guidance on:

1. Avaya processes that may reset service accounts or authorized_keys over time
2. Known key/algorithm compatibility changes after patch/upgrade on telephony nodes