Subject: Re: [Summer of code] Proposal : a Sftp server
To: None <tech-userlevel@NetBSD.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 06/14/2005 23:35:08
> Every time I use sftp, I miss the features of a typical ftpd. The
> most obvious one is [tab] name-completion,
That is not a feature of ftpd (the server), but of ftp (the client).
> I don't understand why sshd isn't just a better inetd. IOW, why
> can't it accept a connection, authenticate the user, and hand it off
> to the next layer?
It can, sort of. That's more or less the way scp worked (and still
works, where it exists, as far as I can tell): after authentication,
the client sends over a command string to run (scp -R blah blah) and
talks to the resulting process.
I think the reason sftp exists is to make it possible to provide file
transfer *without* providing shell access, though since I didn't design
it I am not really competent to comment on its original motivation.
> Why can't ftp & fptd be taught to speak ssh, instead of replacing
> them with new, feature-poor versions?
Probably because it's less work to write the new sftp.
I suspect that by the time sftp has been around as long as ftp now has,
it will be comparably featureful to modern ftp.
If you think it would be better to layer something FTPish atop ssh,
well, I say go for it. If your way proves better, it could very well
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML firstname.lastname@example.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B