No matching key exchange method found (SFTP)

Your SSH client and DocEvent's server have no key exchange method in common, so the connection stops before login. With DocEvent this almost always means the client is old, or configured to offer only a narrow list. Update the client, or let it use a modern method such as curve25519-sha256.

Unable to negotiate with <ip address> port 22: no matching key exchange method found.
Their offer: mlkem768x25519-sha256,curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,kex-strict-s-v00@openssh.com

Why it happens

Before anything is encrypted, the client and server each send the key exchange methods they support and must agree on one. When the two lists do not overlap, the client gives up with this error.

"Their offer:" is the other side's list. Your client printed the error, so that list is what DocEvent's server offers - none of your client's methods are on it. The usual causes:

• An old client or library that only offers diffie-hellman-group1-sha1 or diffie-hellman-group-exchange-sha1.
• An SSH config or application setting that narrows the list to methods we do not offer, such as diffie-hellman-group-exchange-sha256 alone.

Check what your client offers

With OpenSSH (the ssh, sftp and scp commands), this prints the list your client will send to DocEvent, after your config files are applied:

ssh -G sfs-us-east-1.docevent.io | grep -i kexalgorithms

ssh -Q kex is different: it lists everything your build supports, including methods turned off by default.

To watch the negotiation, add -vv. The KEX algorithms: line after local client KEXINIT proposal is yours; the one after peer server KEXINIT proposal is ours.

For WinSCP, FileZilla and other graphical clients, check which version you run - this error usually means it is out of date.

How to fix it

1. Update the client or library. A current OpenSSH or WinSCP supports methods DocEvent offers.

2. Remove a restricting KexAlgorithms line from ~/.ssh/config or /etc/ssh/ssh_config, or override it for DocEvent hosts:

   Host *.docevent.io
       KexAlgorithms +curve25519-sha256
   

   OpenSSH uses the first value it finds for each option, so put this block above any Host * block. The + adds to OpenSSH's default list instead of replacing it.

3. Libraries and connectors (Java, Python, .NET, ETL tools): upgrade the SSH library. If your code pins a key exchange list, add curve25519-sha256 or ecdh-sha2-nistp256 to it.

Re-enabling diffie-hellman-group1-sha1 with KexAlgorithms +... will not help: that workaround is for reaching an old server, and ours do not offer it.

What DocEvent accepts

As of October 2026, every region's SFTP and SCP servers offer, in this order:

• mlkem768x25519-sha256
• curve25519-sha256 (also as curve25519-sha256@libssh.org)
• ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521
• diffie-hellman-group14-sha256
• diffie-hellman-group14-sha1

kex-strict-s-v00@openssh.com, at the end of the list, is not a method your client can pick. It signals "strict key exchange", the protection against the Terrapin attack.

Not offered: diffie-hellman-group1-sha1, diffie-hellman-group-exchange-sha1, diffie-hellman-group-exchange-sha256, diffie-hellman-group16-sha512 and diffie-hellman-group18-sha512.

diffie-hellman-group14-sha1 is the only SHA-1 method on the list. SHA-1 is being retired across SSH - OpenSSH dropped this method from its own default list in release 8.2 (2020) - so make sure your client picks one of the others. With -v, the kex: algorithm: line shows which one was chosen.

If the Their offer: list in your error does not match the one above, you are not reaching DocEvent's cloud service - check the hostname and any proxy in between. A self-hosted server started with -sshdisablesha1 also leaves out diffie-hellman-group14-sha1.

Related errors

"no matching host key type found" is the host-key version of this error - see ssh-rsa client compatibility for SFTP. To confirm you are talking to DocEvent, compare the fingerprint in SSH host keys.

If an up-to-date client still fails, capture the output of sftp -vv ... and send it to support.