OpenSSH 10 Crypto Changes: Why Old SFTP Integrations Need a Cleanup Plan

By Greg Nowak. Last updated 2026-06-24.

As of June 24, 2026, the current OpenSSH 10.x release line is 10.3, and the compatibility work that started in 10.0 is no longer theoretical. If your company still depends on long-lived SFTP drop-boxes, nightly file pushes, vendor collection scripts, or agency-run client automations, the risk is not only that SSH may fail. The larger risk is that nobody owns the detail until payroll, reporting, fulfillment, or a client handoff misses a file.

What Changed In OpenSSH 10

OpenSSH 10.0 removed support for the DSA signature algorithm. That matters because a server or client that still depends on DSA is not merely using an unfashionable key. It is depending on key material OpenSSH has now retired after years of deprecation. For a business owner, the practical answer is simple: DSA keys should be replaced, not worked around.

OpenSSH 10.1 added a client warning when a connection negotiates a key exchange that is not post-quantum. The transfer may still succeed, but the warning is a useful early signal. OpenSSH explains the issue as the risk of encrypted sessions being captured today and decrypted later if future quantum computers can break the key agreement. The relevant fix is usually on the server side: support modern hybrid key exchanges such as mlkem768x25519-sha256 or sntrup761x25519-sha512, and make sure local policy has not disabled them.

OpenSSH 10.0 also narrowed server-side defaults by removing the older finite-field Diffie-Hellman group and group-exchange methods from the default server KexAlgorithms list. OpenSSH 10.3 adds another reminder for brittle integrations by removing bug compatibility for implementations that do not support rekeying. In plain English: old transfer paths can break for more than one crypto reason, and version numbers alone do not tell you what will actually negotiate.

Signal	Likely Cause	First Business-Safe Action
DSA key fails after an OpenSSH update	The integration still relies on retired DSA key material	Replace the key and test the exact batch job end to end
Non-post-quantum warning appears	The server does not offer a supported hybrid key exchange	Upgrade or reconfigure the server before suppressing warnings
Key exchange mismatch	Client and server no longer share acceptable KEX algorithms	Inspect both sides and avoid estate-wide legacy fallbacks
Manual login works but automation fails	The job uses a different identity, config path, or agent state	Pin the intended identity and test with batch-mode settings

A practical triage matrix for OpenSSH 10 SFTP cleanup work.

Start With Inventory, Not Exceptions

The wrong first move is to paste legacy algorithms into a global SSH config and hope the warnings stop. Start with an endpoint register: host, port, owner, vendor contact, business process, schedule, client version, server version if known, authentication key, host key, negotiated key exchange, and whether the job is interactive, batch, or embedded in another tool.

OpenSSH gives you useful inspection commands before you touch policy:

ssh -Q kex
ssh -Q HostKeyAlgorithms
ssh -Q PubkeyAcceptedAlgorithms

Those commands show what the installed client can support. Then test the real job path, not a convenient manual shortcut. If the production task uses SFTP, batch mode, a named key, and a cron environment, test that shape directly:

sftp -vvv -oBatchMode=yes partner-legacy-sftp

The goal is to find the negotiated behavior, not to prove that some SSH connection can be made from a developer laptop.

Replace Weak Keys Cleanly

Where DSA appears, plan a controlled key replacement. Ed25519 is a good default when the partner system supports it, while RSA with SHA-2 signatures may be needed for some older commercial appliances. The important part is not the key type alone. It is the rollout: create the new key, install the public key with the partner, test in parallel if possible, update the automation, and remove the old key from authorized access.

ssh-keygen -t ed25519 -f ~/.ssh/vendor_sftp_2026 -C vendor-sftp-2026

For unattended jobs, pin the intended identity so the job does not accidentally succeed because an agent offered a different key:

Host partner-legacy-sftp
    HostName sftp.partner.example
    User upload
    IdentityFile ~/.ssh/vendor_sftp_2026
    IdentitiesOnly yes

Keep Exceptions Small And Visible

Some partners will not modernize on your timeline. That is normal, but it should be handled as an explicit exception. The OpenSSH client supports Host and Match blocks, and WarnWeakCrypto can suppress the post-quantum warning for a specific host. Use that carefully:

Match host partner-legacy-sftp
    WarnWeakCrypto no-pq-kex

That line is not remediation. It is a documented risk acceptance while the server owner catches up. Put a reason, owner, and review date beside it in your endpoint register. Do not put the same setting under Host *, because that teaches every future SSH connection to be quieter when it should be more informative.

What A Good Cleanup Project Leaves Behind

A useful OpenSSH 10 cleanup is small but disciplined. It should leave you with modern keys where possible, scoped compatibility settings where unavoidable, a record of which endpoints still need partner action, and simple monitoring around the transfers that matter. For most teams, that means alerting on failed exits, missing expected files, and new crypto warnings during the migration window.

For agencies, the same approach can be packaged across client estates without turning every exception into a permanent custom snowflake. For operations leads, it gives you something better than a vague security concern: a finite list of endpoints, owners, risks, and fixes. If you want this handled as a contained engineering project, talk to Greg about an SSH/SFTP cleanup.