views:

829

answers:

5

Which is generally considered "best practice" when wanting to securely transmit flat files over the wire? Asymmetric encryption seems to be a pain in that you have to manage keysets at endpoints and make sure that the same algorithm is used by all clients, where as SFTP seems to be a pain because of NAT issues with encrypting the control channel, thus the router cannot translate IP. Is there a third-party solution that is highly recommended? Thanks for any suggestions.

A: 

Use PGP / GPG and transfer the gpg-ed file directly via ftp or any other method.

Iulian Şerbănoiu
+1  A: 

rsync is the best file transferring utility out there. Supports resume, recursion and a variety of encryption including ssh (the default). Like scp on steroids.

If you have multiple routers to punch through you can build ssh tunnels. It will only transfer parts of the file that are missing which make it great for backups. It has so many useful features I use it instead of cp for local copying.

It's available for many platforms and included by default on modern *nix systems. More at http://samba.anu.edu.au/rsync/

Jonah Braun
+3  A: 

I believe you're talking about FTP with SSL when you say SFTP, and not the SFTP protocol that goes along with SSH. Use SFTP (the SSH version) as it doesn't require an encrypted control channel and will work fine over NAT. The SFTP page I linked to lists a number of graphical SFTP clients at the bottom of the page.

Jason Terk
Actually FTP with SSL is known as FTPS; you were thinking that he was thinking of FTP tunneled over SSH (as opposed to the seperate SFTP protocol you referred to).
AviD
A: 

Yah, I meant SSL FTP, not SFTP. "Management" is adverse to open-source, but if that's what the de-facto best practice is, then that's what to use...thanks for answers

Feel free to ask your management to buy closed source SSH from http://www.ssh.com/I remember when we free software zealots wouldn't use SSH because it wasn't free. Nowadays OpenSSH is fine.
slim
A: 

With FTPS, you can generally switch to an unencrypted control channel via the CCC command after authentication. This approach means no problems with routers, while the data you are transferring will remain encrypted.

Bruce Blackshaw