While troubleshooting this, start a packet capture on the server for its ssh port.

Have them update their sftp software to be sure it has modern algorithms. Key exchange algorithms are updated over time as cryptography research makes older methods insecure. Compare to ensuring a TLS encrypted https session exists before sending secrets to a web server. The entire point of the ssh protocol is to establish an encrypted channel where it is possible to send such weak authentication as passwords over insecure networks.

This is different from user authentication, where user keys or passwords or Kerberos are among the options. This a real challenge when the failure is during the protocol negotiation phase of establishing an SFTP session.SSH key exchange establishes a one-time session key, and authenticates the server via its host key. That doesn't give an visibility into the action that is failing. AutoMate only logs actions to the FTP log AFTER they complete. I did come to the forums today to open a new thread about a side issue you are facing: the low transparency of AutoMate's FTP/SFTP engine when things don't work. For most workflows that have these failures, re-running the workflow usually re-establishes the SFTP session and completes the download or upload successfully. It is seems to affect workflows that connect to certain servers more than others. Some failures occur while AutoMate is setting up the connection, while others happen in the middle of a transfer. I do have some connections to some servers where the connection is lost from time to time. A couple of my SFTP file transfer workflows use SSH keys for authentication and encryption successfully. I have not encountered the specific situation and failure that you are wrestling with.

Filezilla connect to ssh server