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