Ben Harris wrote:
> This is a client issue, not a server issue.  ftpd no more loads your
> shell than httpd does.

Thank you for the education.  Not to drift too far off topic, but now I'm
completely baffled by why ftpd insists the user have a valid shell (item
#3 under "User Authentication" on the ftpd man page).  

I arrived in Unixland only in 1999, and I've had to learn my history
backwards, you see.  

> >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?
> 
> That's precisely what the "Subsystem sftp /usr/libexec/sftp-server" in
> sshd_config does.  If you want a better sftp server, replace it there.

It is and it ain't, if I may say so.  In contrast to inetd, there's no
general, open-ended, well defined interface between sshd and sftp-server. 
Maybe it's just a dearth of documentation, but afaict sftp-server is
tailor-made to fit sshd's demands.  I'm unaware of any other subsystems
for sshd.  

It would be nice, I think, to write simple programs that use stdio, and
wire them up to ssh to get authentication and encryption for free.  

> >  Why can't ftp & fptd be taught to speak ssh, instead of replacing
> >them with new, feature-poor versions?
> 
> Remember that FTP can't be run over a single byte-stream -- it needs a
> separate stream for each data transfer.  

Sure, I know.  You just saying it's not a simple swap-in, and I agree.  We
both know there are a few ways to compensate.  I was speculating that
rather more of the ftpd/ftp functionality is devoted to things that aren't
specifically communications.  As Mouse suggested, it could be that writing
a new pair was less work than enhancing an old one.  Of course, it's
frequently easier to do less....

Regards, 

--jkl