[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Secure FTP?


Trust me, a subscription to System/I Network will be the best ~$200 you will spend all year, even if all you do is get the sftp articles. It will save you and your company lots of time and pain.

Duane Christen 


 	 	Duane Christen
Senior Software Engineer
(319) 790-7162
Visit PAETEC.COM	  	

-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of daparnin@xxxxxxxxxxxxxx
Sent: Monday, October 25, 2010 3:19 PM
To: HTTPAPI and FTPAPI Projects
Subject: Re: Secure FTP?

Thanks everybody for the feedback.  This gives me a direction.  I just have the basic System/i Network access which isn't good enough to get to the articles but I'll dig around and see what I can find.

Dave Parnin
Nishikawa Standard Company
324 Morrow Street
Topeka, IN  46571
260-593-2156  ext. 621

From:   Scott Klement <sk@xxxxxxxxxxxxxxxx>
To:     HTTPAPI and FTPAPI Projects <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
Date:   10/25/2010 03:25 PM
Subject:        Re: Secure FTP?
Sent by:        ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx


On 10/25/2010 12:55 PM, Shahar Mor wrote:
> can you please describe the reason behind your  recommendation for
> openssh rather than ftps ?

1) FTPS isn't as secure as SSH.  Here's my description of why:

2) FTPS is not as widely used as SSH

3) FTPS is difficult to get working through a firewall, creating much 
pain and headaches and unreliability.

> The openssh does not support exit programs which are part of security
> schema of many shops in the as400

We're talking about the _client_ side of communications here, not 
server.  Security the client side with an exit program makes no sense.

As an analogy:  Imagine if banks didn't have big, secured locked, 
vaults, but instead went to every would-be bank robber's house, and 
nailed their doors shut.  Instead of protecting the money in the bank, 
they went to every possible thief's house and locked them inside, thus 
preventing them from coming to rob the bank!   It wouldn't work, would 
it?  The robber would just find another way out of the house.  Or even 
if he couldn't, another robber would.  Somehow, some way, the bank would 
miss one of the robbers.  You can't secure them inside all of their 

But that's pretty much what you're suggesting when you try to secure 
data by locking down the client.  You need to lock down the SERVER (the 
bank vault) not the client!  Exit programs on the client make no sense.

> and it is more difficult to establish batch oriented sftp client

I challenge that.  I don't think it's more difficult -- I think it's 
much easier!

an FTPS script to download all files from a directory, then delete them 
from the server:

klemscot bigboy
cd /the/directory
mget *
mdel *

What's wrong with this script?

1) The userid/password are hard-coded. That's not good, because now 
anyone with access to my source code or compiled object can get my 
password.  Now I have to write a system to replace that password 
on-the-fly... more work, and more difficult.

2) Worse, if this is to be automated, I need to also encrypt that 
password, and protect the key somehow, since I can't have a user typing 
it at run-time.  Now I need to learn cryptography, and I need to get it 
right.  Since I'm writing the cryptography myself, I don't have a large 
community of crypto-experts to help me.  If I make any mistakes, I'm 

3) If the 'cd' command fails, it'll download all of the files from the 
wrong directory, since the script will just continue running.

4) If the mget command fails, it'll still delete all of the files from 
the directory with mdel, because the script will continue.

5) After it completes, my program needs to know if it succeeded or 
failed.  My only information about that is an output log file -- I'll 
need to write a complex RPG program to interrogate that log.  I must be 
careful to get it right, since I don't know exactly which messages will 
occur at run-time.  If anything is wrong, I must detect it by analyzing 
the log file, or I won't know that it failed.

Now let's look at the same thing with sftp (remember, you told me this 
would be _harder_)

cd /the/directory
get *
del *

Notice that it's almost identical.  What happened to it being harder?

1) the userid is passed on the sftp command, not hard-coded in the script.

2) the password is eliminated, and a secure digital key is used in it's 
place.  The cryptography behind the key was designed and tested by a 
large community of crypto experts who actively maintain it's security.

3) This script will abort when the commands fail.  It will not simply 
proceed.  That way, I dont' have to worry about the get being run if the 
cd fails.  Likewise, I don't have to worry about the del being run if 
the get fails.

4) After the script ends and my program regains control I can 
immediately tell if it succeeded or failed by checking the exit 
status... no need to try to analyze and interpret a complex output log.

This is the FTPAPI mailing list.  To unsubscribe, please go to:

This is the FTPAPI mailing list.  To unsubscribe, please go to: