sftp algorithm negotiation fail

[runninglogic]

I have a channel on Mirth 3.12 that is trying to make an SFTP connection. When I test the SFTP connection it gives me an error reason of "Algorithm negotiation fail". I am able to make a connection using Filezilla but not through Mirth. Has anyone had this issue and been able to resolve it? Thanks!

[pacmano1]

Mirth uses jsch for SFTP, I would google that error for things like https://stackoverflow.com/questions/6263630/jschexception-algorithm-negotiation-fail

[jonbartels]

The problem sounds familiar but I don't recall the solution. https://forums.mirthproject.io/search?q=sftp+algorithm&searchJSON=%7B%22keywords%22%3A%22sftp+algorithm%22%7D seems to have some solid leads.

What error, if any, is in mirth.log?

If you control the SFTP server, what errors are in its logs?

[runninglogic]

Thanks for the suggestions. I will take a look at the links that you provided. The SFTP server is not ours so I cannot check the logs. I have created a windows scripting job to handle things for now.

Thanks,
Paul

[JoeFox82]

Yesterday I updated a Mirth from Version 3.9.1 to 4.5.0. After that all my SFTP connections are broken. When testing the connection by clicking the "Test read" button Mirth says

I tried this solution (Page 2, last post): https://forums.mirthproject.io/forum/mirth-connect/support/13545-sftp-unable-to-connect-algorithm-negotaition-fail/page2 but it didn't work.
After that I updated Java (Eclipse JRE) from Version 8 Update 292 to Update 405 but it didn't work.

Any idea?

Thanks!

[pacmano1]

Did you look at https://github.com/mwiede/jsch?

[JoeFox82]

You are right. I now looked at the slack channel, too. Seems that there are several ways to fix the problem, depending on the other system configuration.

[jonbartels]

If you connect to the remote using verbose options from the command line (sftp -vvvvvvvv) or with FileZilla you should be able to see what algorithms the remote side supports and negotiated with the client. You may need an algo other than ssh-rsa to make the supported sets between jsch and your server overlap.

BTW - your early experiments and screenshots were VERY helpful in making the case to upgrade JSch. I am sorry you're getting errors now but that upgrade was a big step and helped improve mirth.

[JoeFox82]

Got it working!

I only had to set this option in the Method Settings:

When you got an error like me shown above in the post then you will see a part serverProposal on the right of the error message

You have to set one of this values as value for kex in the Method Settings. This are the algorithms the server can handle.

I hope this will help others to get Mirth working with your SFTP using older algorithms ;-)

[ChristopherSchultz]

I'm getting the same sort of error, but this time for server_host_key. I tried setting server_host_key in the Configuration Options under SFTP Settings as shown in @JoeFox82's screenshot above, with the value being the original jschProposal plus , plus the value of the serverProposal value, which was ssh-rsa. The value shown in the error message doesn't seem to change, which makes me think I haven't "spelled" something correctly in the configuration. I'll copy/paste it here to be sure:

server_host_key=ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,rsa-sha2-512,rsa-sha2-256,ssh-rsa

I used sftp from the CLI to see what happens, and the debug log looks like this:

debug1: Authenticating to example.com:22 as 'ec2-user'
debug3: hostkeys_foreach: reading file "/home/ec2-user/.ssh/known_hosts"
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,ext-info-c,[email protected]
debug2: host key algorithms: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ssh-dss
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected],zlib
debug2: compression stoc: none,[email protected],zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group15-sha512,diffie-hellman-group16-sha512,diffie-hellman-group17-sha512,diffie-hellman-group18-sha512,rsa2048-sha256,ecdh-sha2-nistp384
debug2: host key algorithms: ssh-rsa
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: MACs ctos: hmac-sha256,[email protected],hmac-sha2-256,[email protected],hmac-sha512,[email protected],hmac-sha2-512,[email protected]
debug2: MACs stoc: hmac-sha256,[email protected],hmac-sha2-256,[email protected],hmac-sha512,[email protected],hmac-sha2-512,[email protected]
debug2: compression ctos: none,zlib
debug2: compression stoc: none,zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: ecdh-sha2-nistp384
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-ctr MAC: [email protected] compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: [email protected] compression: none
debug1: kex: ecdh-sha2-nistp384 need=32 dh_need=32
debug1: kex: ecdh-sha2-nistp384 need=32 dh_need=32
debug3: send packet: type 30
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ssh-rsa SHA256:[signature]

Any suggestions? I've re-deployed the channel after changing the configuration, of course.

[JoeFox82]

Can you please post the error message you get?

[ChristopherSchultz]

The error is: Algorithm negotiation fail: algorithmName="server_host_key" jschProposal="ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,rsa-sha2-512,rsa-sha2-256" serverProposal="ssh-rsa"

I'm beginning to wonder (since the message does not change) if the message is actually still erroring on the SFTP part. I see no related messages in mirth.log, etc. but I can't be 100% sure at this point if "the error" that is causing the queuing of this message is actually the Jsch one. Is it possible to "clear" an error from a message to be sure that what shows up under the "Errors" tab is coming from the most-recent-processing-attempt?

[JoeFox82]

You said, that when you set client_pubkey and server_host_key to ssh-rsa the Test Write button says "Connection successful". When you try this again, what error do you get? I think that is the right configuration depending on your error message.

As far as I know the error message stays for the first queued and then send message vin the queue. You have to reprocess / overwrite the message again. When the error doesn't accure anymore, the error tab wil disappear.

[jonbartels]

Is it possible to "clear" an error from a message to be sure that what shows up under the "Errors" tab is coming from the most-recent-processing-attempt?

Reprocess and keep the "overwrite" checkbox unchecked.

[ChristopherSchultz]

Something else is going wrong, here. I created a new channel connecting to the same remote host and it works with the server_host_key overidden.

I will probably just adapt the new channel to be the channel or maybe just create a new destination and see if that works. But for whatever reason, this destination or channel seems to be poisoned.