AIX

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

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

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

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

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!

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

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

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

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.

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

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

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.

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