(no subject)

Robert Connolly cendres at videotron.ca
Sun Mar 7 04:26:42 PST 2004

On March 7, 2004 05:49 am, Ian Molton wrote:
> On Sun, 7 Mar 2004 00:22:10 -0500
> Archaic <archaic at indy.rr.com> wrote:
> > I don't buy that as a wholesale statement. Every single time I've ever
> > used sftp or scp on a large file, the transfer time was hideous
> > compared to straight ftp. If I need something to travel the pipes
> > encrypted, then fine. Otherwise I'll stick to ftp (or more likely http
> > since I don't have tons of stuff laying around for public consumption
> > of my bandwidth).
> Theres no requirement to have the data encrypted. however the
> authentication in these packages is FAR better.
> you can even run your ssh session in plaintext if you like use -c none

Ftpd would be okay for real users if the authentication was encrypted, but 
both server and client would have to support this. The file transfer would be 
clear, but if the file is intented to be public information then no one 
cares. I have tried out using `sftp -oCipher=none` and `scp -oCipher=none`
compared to normal `scp` and `sftp`, and I found the traffic speed was 
identical. If compression was set the server used so much cpu the traffic 
speed dropped by about 65%, from 450kbps to 160kbps. But this isn't ftpd its 
sshd. WIth ftpd I get just over 800kbps :) With https its about 400kbps, and 
to my surprize httpd did best, getting to 815kbps. So, SSL seems to reduce 
speed by about 50%, on my server.

Many ftpd's have kerberos support that would probably work nicely if you want 
real and anonymous users using the same service.

Login sessions should be completely encrypted, for you and your server's 
privacy. Doing /sbin/ifconfig -a can send out the ethernet MAC address to 
network sniffers who would otherwise not have access to them. Among other 

More information about the hlfs-dev mailing list