From time to time, our sftp scripts fail due to remote server changes - DNS, IP address, certificate update, or other facets of verifying the remote host associated with the certificate.On occasion, the service provider fails to advise us of the change(s) or that an updated certificate is available.

In using sftp and scripts, we have to run sftp manually to update our certificate stores when the service we are transferring records to has had undocumented changes. This infers that we may have multiple event failures before recognizing that a problem occurred (yes, we do have logs, but we don't have a "log monitor" to verify success or failure. This is something we need to incorporate, but isn't the reason for this post.

Generally, the question is how do you handle these unannounced service changes that result in failing to transfer the file(s) to the service provider in a timely manner? Is there a way to verify the certificate in the sftp script and automatically accept the newly-presented certificate? And I recognize there are dangers with that as well - site spoofing or other compromises we or they may not be aware of.

What do you do?

Thanks in advance,

Bob Wyatt

If you're talking about changed public keys, then the answer is SSH certificates, but I never did anything beyond a toy implementation.

Do you mean SFTP (that is an SSH subsystem) or FTPS (that is FTP secured with SSL)?

Lech,

That is sftp, where-in the .ssh folder of the user completing the sftp operation has the public keys file.
Per the documentation, only a manual sftp operation will allow an update to that file.

Regards,

Bob Wyatt.

 P.S. - thanks to all that have replied as well!

I fully understand that you do not want to ignore the situation when server key is different than the stored/verified/confirmed one, as ignoring it would not be acceptable from the security PoV.

However, this means that any time the server key changes you should use the same procedure that should be used when connecting to any server for the first time: use another communication channel to transfer the fingerprint and verify that value against the fingerprint of the server key received during the initial connection attempt. While it is possible to automate this (say receive the fingerprint in S/MIME signed email message, verify signature, extract the fingerprint and use some kind of a script - eg expect - to launch sftp connection, verify the server fingerprint and so on), usually it's just easier just to do it manually, as server key changes should be quite rare.

You could try -o StrictHostKeyChecking=no, this should have sftp ignore the change of the certificate.  This of course does turnoff the security that is provided by checking for changes to the certificate.

Phill,

We definitely would not want to use the -o StrictHostKeyChecking=no option...

Although we are not transferring financial data, we are transferring data that can be used to identify our clients.
The sending system must maintain PCI compliance standards.

Regards,

Bob Wyatt

Hi Bob,

so I my understanding is, that you sometimes get some warnings / errors about cssh host keys and their fingerprints, after DNS names or IPs have been changed?
Well, that is a security feature, so I agree that disabling it -o StrictHostKeyChecking=no might not be the best choice.

The two other options coming to my mind would be to update .ssh/known_hosts after such a change.  You can remove old entries via ssh-keyscan -R <hostname> and ssh-keyscan -R <ip>. When you now reconnect, you bill asked to verify and accept the host key again, and it will work again till the next dns / ip change.
Other option would be to move the ssh fingerprints to DNS, and tell your ssh client to get and verify them. https://en.wikipedia.org/wiki/SSHFP_record has a short description about these entries.

The first method has the benefit, that it is easier to implement, the second method is more complicate but has the big benefit, that it scales well, if many systems / users would require to update their known_hosts entries.


Best regards,
  Alexander