> There's nothing wrong with offering data over ftp to the general public, > especially when you can guarantee the contents in some way. There is > something wrong when you need secure, private transfers. And what is wrong with it when you need secure, private transfers? > I wonder though, why no-one has mentioned ftp over TLS/SSL, which is a that's because it was oh so cool to use scp to transfer files, and now that's the only way l33t does it. scp is a hack, ftp/tls is an elegant solution, and who would want elegant solutions when they can feel l33t. What is wrong with people, someone ask for a solution, and everybody jumps up to shout - "Hey! I know what is scp!", "Dude, I know rsync". I SOO envy you, I never would've figured out how to use those highly sophisticated tools...
About FTP/TLS: http://www.ietf.org/internet-drafts/draft-murray-auth-ftp-ssl-12.txt describes a mechanism that can be used by FTP clients and servers to implement security and authentication using the TLS protocol defined by [RFC-2246] and the extensions to the FTP protocol defined by [RFC-2228]. http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html contains a list of clients and servers that supports the FTP TLS/SSL protocols, plus alot of additional info. simple tools like lftp support those almost-decade-old specifications, there's no need to create shell accounts on your system for every person who wants to transfer files, specification is clean and simple. There ARE scenarios where scp/sftp would fit better - for example you want authentication based on private/public key. Support for that is very stable with ssh, with ftp you would be pressed hard to find server that works like that. -- Dariush Pietrzak, Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9
