An automation job that worked before a package upgrade now reports Incompatible ssh peer. Before changing passwords or disabling security settings, identify which negotiation failed. Host-key algorithms, key exchange and user authentication are related parts of SSH, but they are not interchangeable.
Lab status: This is a proposed exercise, not a completed device test or client case study. Code examples require validation against your image and dependency versions. My documented background is NOC/data center operations, multi-vendor Netmiko workflows and Python/Flask integration.
Offline example checks: October 20, 2026: the added helper/demo block executed with local fixtures, and related negative cases were checked offline. No live device, controller, fabric or service behavior was validated.
How do host-key and KEX negotiation errors differ?
No acceptable host key concerns the server identity algorithm that the peers can agree to use. No acceptable kex algorithm concerns key exchange. A login rejection happens later. Keep the complete exception because a shortened dashboard label can remove the detail needed to choose the next test.
Keep host-key algorithm negotiation separate from host identity verification. Two peers may share an algorithm while the stored key no longer matches. KEX agreement establishes a key-exchange method; it is not a password check. An authentication rejection therefore needs another diagnostic branch.
Why can a dependency upgrade expose an SSH mismatch?
Record the old and candidate virtual-environment lock files. Compare client-supported algorithms with the device’s authorized SSH configuration or a restricted diagnostic transcript. Do not invent a negotiated algorithm from a successful manual login: OpenSSH and Paramiko may advertise different preferences.
Proposed lab: compare SSH client and server compatibility
Use one unchanged lab SSH server and two isolated client environments. A comparison matrix needs client version, server release, host-key family, KEX family and actual outcome. Preserve a changed-host-key failure as an identity incident until an authorized owner verifies the replacement fingerprint.
Python: record Paramiko and cryptography versions
The additional helper compares reviewed algorithm lists without making a connection or enabling anything. Its synthetic input is not a statement about Paramiko defaults. A shared name only establishes possible overlap; negotiation can still fail because of policy, signatures, host identity or another stage.
import platform
from importlib.metadata import version, PackageNotFoundError
print('Python:', platform.python_version())
for name in ('paramiko', 'cryptography', 'netmiko'):
try:
print(name, version(name))
except PackageNotFoundError:
print(name, 'not installed in this environment')
Worked Python example and input contract
def compare_algorithms(client, server):
# Inputs are reviewed algorithm-name lists, NOT inferred from a login failure.
result = {}
for family in ('host_key', 'kex'):
offered, accepted = client.get(family), server.get(family)
if not isinstance(offered, list) or not isinstance(accepted, list):
result[family] = {'status': 'unknown', 'shared': []}
continue
shared = sorted(set(offered) & set(accepted))
result[family] = {'status': 'overlap' if shared else 'no_overlap', 'shared': shared}
return result
client = {'host_key': ['ssh-ed25519'], 'kex': ['curve25519-sha256']}
server = {'host_key': ['ssh-ed25519'], 'kex': ['diffie-hellman-group14-sha256']}
print(compare_algorithms(client, server)) # Synthetic reviewed lists
What should you check before changing SSH algorithms?
Prefer supported server firmware and a documented compatible client. If an organization approves a temporary per-host legacy exception, record its scope, owner and expiry. Do not use AutoAddPolicy, remove a known-host entry or change fleet-wide crypto policy to make the example pass.
When would another CLI library address the requirement?
A second transport is useful as a controlled comparison when its identity policy and offered algorithms are recorded. Its success does not prove the first client is broken. Keep device mode, commands and resulting state equivalent before planning a rewrite.
How should you validate and scope an SSH compatibility fix?
Acceptance requires the expected server identity, successful negotiation under the intended policy and a validated read-only command. The deliverable can be a compatibility matrix and migration recommendation. No synthetic algorithm-set intersection establishes production security or device interoperability.
Related troubleshooting and implementation
Explore the network automation troubleshooting collection to connect this issue to adjacent workflows. The Netmiko, NETCONF and RESTCONF comparison helps when you are choosing an interface rather than fixing an existing implementation.