Shows that FTP+GPG combination cannot be used in place of SFTP – SFTP is still more secure. Also includes a howto document on setting up passwordless SFTP based automated file transfers.

Recently, we needed to setup secure file transfer with a third party that did not support SFTP. Hence we decided to use FTP+GPG – which includes transfer of GPG encrypted files with FTP. For more details on GPG, visit the homepage http://www.gnupg.org/. It can also operate in ‘portable’ mode – from a USB key.

We did not realise that this combination is still significantly less secure that SFTP based transfer. The threats it does not cater to, which SFTP can combat are:

  • Someone can come to know about the username, password used in the connection since this is still being transferred un-encrypted
  • Using this, someone can load their own files into the server which can be designed to either infect the system, or upload malicious information

Even if GPG signatures are used (as we did after coming to know about these shortcomings), there is still the risk of someone replaying the same files that we received. Even this can cause problems in certain situations. Hence, we had to resort to fixing the source IP to combat the problems. Due to using signatures and IP fixing, it all turned out to be more cumbersome, and still less secure.

The best way currently to establish automated file transfers is to do a password-less SFTP. It does not require any password transfer over the network at all, keeps everything encrypted, and: a disgruntled employee who happens to remember a password (in case of password based SFTP) cannot disrupt your services.

This document contains instructions on how to set this up: Password SFTP – How to setup. There is also an online version of the same document. If you have any questions, please post as comments.


4 thoughts on “SFTP>FTP+GPG”

  1. I am facing some issue in setting up the same as it prompts for password even after copying the id_dsa.pub keys to authorized_keys on the destination server.

    I am not aware of the destination host type[whether it is a Windows/unix box] wheras source is solaris10. We have manually created .ssh folder as well copied the keys in authorized file.

    The destination server is a an ftp source.

    Please help me in getting out of the error.

    $ sftp -v ExtremeNetworks@ftp.billport.com

    Connecting to http://ftp.billport.com...

    Sun_SSH_1.1, SSH protocols 1.5/2.0, OpenSSL 0x0090704f

    debug1: Reading configuration data /etc/ssh/ssh_config
    debug1: Rhosts Authentication disabled, originating port will not be trusted.
    debug1: ssh_connect: needpriv 0
    debug1: Connecting to http://ftp.billport.com [] port 22.
    debug1: Connection established.
    debug1: identity file /u002/app/applmgr/.ssh/id_rsa type 1
    debug1: identity file /u002/app/applmgr/.ssh/id_dsa type 2
    debug1: Remote protocol version 2.0, remote software version VShell_3_6_0_252 VShell

    debug1: no match: VShell_3_6_0_252 VShell
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-Sun_SSH_1.1
    debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible
    Unknown code 0

    1. You will need to find out more about the destination as well, or take help from a designated admin for the destination machine. Working blindly may not find results.

      Search for google for this error message. Sorry, cant help further without more information.

  2. The problem with SFTP file transfers is that performance is absolutely terrible. I am trying to find a solution for transferring hundreds of gigabytes across a network in the fastest AND most reasonably secure way possible. Do you have any suggestions? I’ve been googling for a solution for quite a while no, to no avail…

    1. It may be worthwhile to take your question to GNUPG users list. People over there have battled with this.

      Have you considered using rsync?

Leave a Reply

Your email address will not be published. Required fields are marked *

Licensing and information about the blog available here.