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