AGlauser@xxxxxxxxxxxx wrote:
Another option that I don't think Scott mentioned would be to request
that you be given all of the possible host fingerprints over a
different trusted channel. Then, your known_hosts file would know to
trust whichever server you happened to be connecting to that day.

Hmmm... never tried this, but I don't think it'd work. It uses the
host name as a key to look up the fingerprint in the known_hosts file.
The problem (as I understand it) is that there's one host name, but
somehow it goes to multiple hosts (perhaps using a load balancer of some
kind). I'm not sure that the known_hosts file understands the idea of
having multiple keys for the same host name.

I suppose you could have multiple known_hosts files, and try using each
one (one at a time) until one of them worked...


Transferring already-encrypted data via 'normal' FTP ought to be
almost as secure as using SFTP. It might be worth metioning that to
your trading partner - you could use your original idea, minus the
"old fashioned" hardware.

I certainly don't agree with that. It's more secure to "ignore the problem" (by deleting the key from known_hosts and turning off strict host key checking as I outlined in my last message). Sure, that doesn't protect against man in the middle attacks, but at least it sends an encrypted userid/password.

Plain FTP sends plaintext userid/password. Plus, it's even more vulnerable to "man-in-the-middle" since they could potentially intercerpt the PORT command or response from PASV command in order to redirect the data channel without even redirecting the command channel.

So I'd definitely suggest that you stay with sftp, even if it means deleting the key from the known_hosts file (or deleting the known_hosts file if it doesn't matter for other apps). Much more secure than plain FTP. Just not as secure as it could be...

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.