Dennis HilkLinux Fix LabDE

SSH, Security & Permissions

SSH peers cannot agree on algorithms

Older appliances may offer algorithms disabled by a current client. Distinguish host-key and key-exchange negotiation before acting.

Editorial source review: Start with the evidenceShare this guide
On this page
  1. Symptoms & scope
  2. Possible causes
  3. Diagnose safely
  4. Evidence-guided next steps
  5. References & review
  6. Related problems

Symptoms & scope

  • Connection stops before account authentication.
  • The error lists the peer’s host-key or key-exchange offer.

Relevant environment

OpenSSH client connecting to an appliance or older server; query modes require no network connection.

Recognizable messages (synthetic examples)
Unable to negotiate with 192.0.2.40 port 22: no matching host key type found. Their offer: ssh-rsa

This fails before user-key authorization; adding authorized_keys cannot repair this negotiation.

Unable to negotiate with 192.0.2.40 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

Inspect KexAlgorithms and the peer firmware; this is distinct from host-key and password errors.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

  • The peer may support only obsolete algorithms.
  • A host-specific client policy may exclude otherwise shared algorithms.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Replace HOSTNAME with the appliance alias; prints effective hostkeyalgorithms and kexalgorithms without connecting.

ssh -G HOSTNAME

Interpret the result: Compare the relevant list with the exact error offer. HostKeyAlgorithms and KexAlgorithms control different negotiation steps.

Check 2

Shows algorithms compiled into the client, not necessarily those enabled by default.

ssh -Q HostKeyAlgorithms

Interpret the result: If the peer’s only host-key algorithm is absent, a configuration exception cannot add it. For key exchange, query ssh -Q kex separately.

Evidence-guided next steps

Update the peer’s SSH implementation

If the peer offers only legacy algorithms, use its supported firmware or SSH upgrade path to enable modern host keys and key exchange. Verify new host-key fingerprints through the console before replacing client trust entries.

Precautions: Save appliance configuration and confirm a vendor-supported recovery path before changing firmware.

Recovery / rollback: Use the vendor’s documented firmware rollback and restore the saved SSH configuration if supported.

Did this solution help you?

Share this solution#

Scope a temporary exception to one verified host

If modernization is temporarily impossible and policy permits the risk, add only the exact offered algorithm to the relevant option in a Host block for that verified appliance. A leading + appends rather than replaces modern defaults. Remove the exception after the upgrade.

Precautions: Weak algorithms reduce protection. Do not apply a wildcard Host * exception or change unrelated cipher and signature settings.

Recovery / rollback: Delete the single host exception or restore the saved SSH client configuration.

Did this solution help you?

Share this solution#

References & review

This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.