× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



jmmckee@xxxxxxxxxxxxxx wrote:
Now, below is the screen I get when I attempt to connect to an sftp
site. This connection works with FileZilla, but not with sftp. Is
there a parameter I need to use? I changed the site name in the
message, in case anybody wonders why it looks strange.

This is what SSH is *supposed* to do. It's protecting you against man-in-the-middle attacks.

You see, SSH's encryption stream will encrypt data as it travels over the internet. The only place the data can be read (unless of course someone cracks the encryption) is on the site where it's sent from, and the site where it's sent to. And that's what you want, right?

The problem is: This protection doesn't help if you're connecting to the wrong site! It does you no good to send the data encrypted, if you connect to evilhacker.com and send them all of your secrets.

The reason we encrypt private Internet data is because we don't have a direct connection to the computer we're sending it to. Instead, we have to go through routers on other people's networks. Our Internet provider's network, for example. And whomever provides our ISP's internet feed. And so forth. Then the Internet backbone. Then the ISP on the other end of the connection, etc. Usually your communications will go through 12-15 networks before reaching their destination.

If a hacker is able to compromise any of the computers in that "route over the internet", they're able to see the data you send. So we encrypt it to protect against it.

The problem is... if they're able to compromise one of those routers, they're ALSO able to re-direct the connection to another computer. Maybe their own computer! So a solution like SSH/SFTP or SSL can be easily compromised by forcing you to connect to the hacker's computer instead of your intended destination. Once again, the encryption does no good in that circumstance because (as far as SSH/SSL/SFTP can tell) the data is arriving at the intended destination.

That's why SSL has certificates. So you can verify that you're talking to the entity that you expect to be talking to.

It's also why SSH/SFTP has the "known hosts" file. Once you connect successfully ONCE, subsequent connections will verify that they're to the same host. That way, you know you're not being redirected to someone else.

That's why you're getting that "SOMEONE MAY BE DOING SOMETHING NASTY" notice from SSH. Because you're NOT connecting to the same host.

The fact that FileZilla doesn't give you this message is rather scary! I had a high opinion of FileZilla prior to reading your message... now I'm thinking that it's not very secure, and frankly, it's not following the rules of the SSH protocol (which is what sftp uses -- it uses the SSH protocol, not the FTP protocol, to communicate.)

If you really want to bypass this checking, then write a script (to run under PASE) that deletes the host from the "known_hosts" file, and then runs the sftp command with:

sftp -o "StrictHostKeyChecking no"

The StrictHostKeyChecking option controls whether it asks the user whether the host's key fingerprint is correct or not. If you set it to "yes" it'll only connect if the host is already in the known_hosts file. If you set it to "ask" (the default) it'll ask the user whether the host should be added to the known_hosts file. If you set it to "no" it'll automatically add it to the known_hosts file without asking.

SSH/SFTP will never connect to an untrusted host, so you must delete the host's key from the known_hosts file FIRST, then use the above option to stop it from asking the user whether to add the key.

deleting the key from the known_hosts file can be a simple "grep -v" command...

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.