× 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.



Quoting Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>:

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...
--


Thanks for your explanation, Scott. I was never comfortable with what was going
on. The party on the other side is potentially blissfully ignorant. My method
of choice to send data was via modem, and send data as PKZIP with AES256
encryption. But, they don't want to use a modem. Too old fashioned. But, it
is OUR data that could be compromised.

Just another ugly mess.

John McKee


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.