Network Management

NCM automated backup failing for a subset of devices (Connection Refused / SSH Key Exchange Algorithm Mismatch)

NCM's scheduled backup job runs successfully for most devices but fails for a specific subset. The job-level status shows no general error, but individual devices return either a Connection Refused or an SSH Key Exchange (KEX) Algorithm Negotiation Failure.

First published date

7/22/2026 9:23 PM

Last published date

7/22/2026 9:38 PM

Overview

Applies To

  • SolarWinds Network Configuration Manager (NCM) — all versions

  • Scheduled NCM backup jobs (Nightly Config Backup, custom backup jobs)

  • Any device vendor or model where SSH or Telnet is used for config download

Symptoms

  • NCM scheduled backup job completes without a general job-level error (JobEndsWithGeneralError = False)

  • Config downloads succeed for most devices but fail for a specific subset

  • Affected devices show one of the following errors in the NCM job report or NcmBusinessLayerPlugin.log:

    • LoginFailed Message: Connection Refused by X.X.X.X

    • LoginFailed Message: Unable to login to device : Timeout

    • Connection Error: Could not negotiate key exchange algorithm

  • Manual config download for affected devices may also fail

  • Session trace for affected devices shows failure before the authentication step

Product section

Network Configuration Manager

Cause

There are two confirmed root causes for this scenario.

Root Cause 1 — SSH Key Exchange (KEX) Algorithm Mismatch

NCM's SSH library (WeOnlyDo) connects to the device successfully at the TCP level but fails during the SSH handshake because the device does not accept any of the KEX algorithms offered by NCM. NCM never reaches the authentication step.

This is commonly triggered by:

  • Device SSH hardening policies that restrict accepted KEX algorithms to a non-overlapping set

  • Firmware upgrades on the device that removed previously supported KEX algorithms

  • Devices running NX-OS, FortiOS, PAN-OS, or other platforms with strict SSH crypto policies

Session trace signature:

Connection Error: System.Exception: Could not negotiate key exchange algorithm
   at WeOnlyDo.Protocols.SSH2Packet.ChooseCrypto(...)
   at WeOnlyDo.Protocols.SSH.KexInitReceive()

KEX algorithms offered by NCM (NCM 2025.2 through 2026.1):

  • diffie-hellman-group18-sha512

  • ecdh-sha2-nistp384

  • ecdh-sha2-nistp256

  • diffie-hellman-group14-sha256

  • diffie-hellman-group-exchange-sha256

  • diffie-hellman-group14-sha1

  • diffie-hellman-group-exchange-sha1

  • diffie-hellman-group1-sha1

If the device's SSH policy does not allow any of the above, backup will fail at the KEX stage.

Root Cause 2 — Connection Refused

NCM reaches the device at the network level, but the connection is actively rejected before SSH or Telnet authentication. Common causes:

  • SSH or Telnet is disabled on the device

  • An ACL or firewall rule is blocking the polling engine's IP on port 22 (SSH) or port 23 (Telnet)

  • The connection profile assigned to the device in NCM specifies the wrong protocol (SSH vs. Telnet mismatch)

  • The device has reached its maximum SSH session limit

Resolution

Step 1 — Identify Affected Devices from the Logs

Review NcmBusinessLayerPlugin.log (located at LogFiles\Orion\NCM\ in the SWDiagnostics bundle) and search for:

LoginFailed Message: Connection Refused by
LoginFailed Message: Unable to login to device : Timeout
Connection Error: Could not negotiate key exchange algorithm

Compile the list of unique IPs returning these errors. This is the confirmed set of devices where backup is failing.

Step 2 — Collect Session Traces for Affected IPs

Enable session tracing and reproduce the backup job, or retrieve existing session trace files from LogFiles\Orion\CLI\Session-Trace\NCM\ in the SWDiagnostics bundle. Locate the -trace file for each affected IP. The trace file confirms the exact failure point and which root cause applies.

Step 3 — Resolution for SSH KEX Algorithm Mismatch

Option A — Device-side (recommended, no SolarWinds change required):

Have the network team verify which KEX algorithms the device is currently accepting and expand the accepted list to include at least one algorithm from NCM's offered list above. This is a third-party device configuration — the exact command syntax varies by device vendor and OS. Refer to the device vendor's official documentation or contact the device vendor's support for the correct command for your device OS version. SolarWinds does not own, maintain, or support third-party device configuration commands.

Option B — NCM-side via device template KeyExchangeList override (if device policy cannot be changed):

NCM device templates support a KeyExchangeList command that overrides the global SSH KEX algorithm list for specific device types. This can be used to restrict or reorder the KEX algorithms NCM offers for a given device template. Refer to the NCM Device Template Commands documentation for syntax and usage.

Option C — Upgrade to NCM 2026.2 or later (if device requires a KEX algorithm not supported in earlier versions):

NCM 2026.2 introduced additional KEX algorithms not available in NCM 2025.2 through 2026.1. If the device exclusively accepts one or more of the following algorithms, upgrading to NCM 2026.2 or later will allow NCM to successfully negotiate the SSH handshake:

  • mlkem768x25519-sha256 (new in 2026.2)

  • curve25519-sha256 (new in 2026.2)

  • curve25519-sha256@libssh.org (new in 2026.2)

  • ecdh-sha2-nistp521 (new in 2026.2)

  • diffie-hellman-group16-sha512 (new in 2026.2)

If the device accepts any algorithm already supported in NCM 2025.2–2026.1 (see KEX algorithm list under Root Cause 1), upgrading is not required — Option A or B should be applied instead.

Option D — Contact SolarWinds Technical Support for Further Escalation:

If none of the above options are viable, contact SolarWinds Technical Support and provide the following for escalation:

  • The session trace file for the affected device

  • The list of KEX algorithms the device is confirmed to accept (from the device's SSH configuration or vendor documentation)

  • The NCM version and device vendor, model, and OS version

Step 4 — Resolution for Connection Refused

Have the network team verify the following for each affected device:

  • SSH or Telnet is enabled on the device

  • No ACL or firewall rule is blocking the polling engine's IP on port 22 (SSH) or port 23 (Telnet)

  • The connection profile assigned to the device in NCM (Settings > NCM Settings > Connection Profiles) matches the actual protocol enabled on the device

  • The device has not reached its maximum concurrent SSH session limit

To verify and update the connection profile assigned to a device:

  • Go to the node in SolarWinds

  • Click Edit Node > NCM Properties

  • Review the Connection Profile and Transfer Config settings and confirm they match the device's SSH/Telnet configuration

Additional Notes

  • The NCM job-level error flag (JobEndsWithGeneralError) reflects only whether the job itself encountered a fatal error — it does NOT reflect per-device download failures. A job can show no general error while many individual devices fail.

  • If both Running Config and Startup Config types are configured in the same NCM backup job, the built-in job email notification will not send. Split into two separate jobs (one per config type) if email notification is required.

  • If a large number of devices are affected by Connection Refused simultaneously after no recent changes, check whether the polling engine's IP address changed — this may have invalidated existing ACL rules on managed devices.