@dgreenwood: Are you sure that the server is not load balanced?
Also consider upgrading both WinSCP and the server. You are using rather old versions of both.

I have the same problem where I have a group of clients connecting to the same sftp server using the same host key but one client keeps getting the host key doesn't match error. The error happens when using WinSCP to connect as well and not just through scripts that are connecting. I turned on WinSCP logging but I don't see the same thing as described below. I have asked the owner of the sftp server to assist but not getting very far with that.
Could I ask for some assistance or guidance as to what the issue may be or what I could tell the sftp server owner? I've attached the log file from the good and the bad connection

The server offers a list of host key algorithms it supports to the client (WinSCP). WinSCP picks the best out of those it knows. So if you update all your scripts to use ecdsa-sha2-nistp256 hostkey, WinSCP will always pick the ecdsa-sha2-nistp256 and the problem might go away.

I've reported this to WingFTP here: https://bbs.wftpserver.com/viewtopic.php?t=3648

This suggests they're aware of the issue, but I suppose if they don't fix it I don't have much information to go on. Lets hope they do...and that I won't need to come back asking for more information on how specifically a system knows when to determine to issue a new key based on what is seen coming from WinSCP.

The script that consistently gets the same host key has "ecdsa-sha2-nistp256" key:

While the script that keeps getting different keys has "ssh-rsa" key:

The server may have a bug in RSA host key implementation.

Actually, YES other SFTP (not FTP) clients get and can use the same host key all of the time, but those clients are also ALL using WinSCP. So in this situation, we have multiple WinSCP "clients" (all at the same version) connecting to one single WingFTP Server (https://www.wftpserver.com/), but only ONE particular "client" seems to be getting a totally new Key on a daily basis.

Logs are easy to get. Attached is the WinSCP Log from the server that experiences the issue (ServerGetsNewKey.log), as well as the WinSCP Log from a server that does NOT experience the issue (ServerKeepsKey.log). Assuming that the problem isn't with WinSCP and isn't our WingFTP server itself (I have a case open with them as well), what networking property could exist that would cause this behavior?

In other words, what common network firewall or filter rule would cause the server to be told that a new SSH key exists every morning, and not just every time we connect? The server that's told it has a new key every day, is behind a FortiGate (https://www.fortinet.com/) Stateful Firewall. Is there something specific in this firewall brand that would cause this behavior?

jhoag wrote:

Something on the WinSCP client end is causing the server to issue a new key...not sure what condition causes it though?

That's not likely. Are you saying that other SFTP (not FTP) clients get the same host key all the time, while WinSCP not? Do you have logs that show that?

How did you fix it? I'm having the same problem. The key changes daily, yet the FTP server itself is not configured to issue a new key. Something on the WinSCP client end is causing the server to issue a new key...not sure what condition causes it though?

I'll post further if this is still an issue

Host key does not match configured key fingerprint is the error I get. I've had a job running for awhile. The remote server just changed the SSH key, I added instead of updated the key and now when the job runs via task scheduler, I get the above error.

The job in the task scheduler calls a batch file, that's it.
I replaced the key in the batch file and the batch file transfers the file fine.

It gets an error when the task scheduler runs the (same) batch file. I have done the clean up, poked around the registry (but didn't see the keys) and have spent most of the day looking online.

Please help as to where it is pulling the old key from and how to get rid of it. I'm thinking just re-creating the whole site may be best??

Thanks for any help!