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

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
   > 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
   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
   bank vault) not the client!  Exit programs on the client make no
   > 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
   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
   it at run-time.  Now I need to learn cryptography, and I need to get
   right.  Since I'm writing the cryptography myself, I don't have a
   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
   careful to get it right, since I don't know exactly which messages
   occur at run-time.  If anything is wrong, I must detect it by
   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
   2) the password is eliminated, and a secure digital key is used in
   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
   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
   This is the FTPAPI mailing list.  To unsubscribe, please go to:


   1. http://archive.midrange.com/midrange-l/201009/msg00091.html
   2. http://www.scottklement.com/mailman/listinfo/ftpapi
This is the FTPAPI mailing list.  To unsubscribe, please go to: