Subject: Re: [Summer of code] Proposal : a Sftp server
To: None <firstname.lastname@example.org>
From: Aris Adamantiadis <email@example.com>
Date: 06/16/2005 21:26:06
>...hmm? You said "trio" of pipes; I can see one for data in, one for
>data out...and what's the third? (EXTENDED_DATA with DATA_STDERR?)
>How does it do channel requests? How does it hear about channel
>requests made by the other side? How does it open new channels? How
>does it ensure it hears about relevant channel open attempts by the
>peer - and does it approve or reject them?
>And above all, where is all this documented?
Sorry for breaking the subject indentation, I only follow the list through the
sshd currently only interfaces with the subsystems by 3 pipes : Two for the
normal channel data and one for stderr/data_stderr. The only message that can
come from the server to the subsystem is EOF.
Which comes to my idea of doing a ssh library. At least, the subsystem program
can do whatever it wants with the server session. But there is a drawback,
this program has to run on the ssh port ... So a complete solution would
involve a Shell server + a sftp subsystem routine + others subsystems.
And to complete what i've said before, here are the reasons I think sftp does
better than ftps on some points:
-SSH is a protocol that was designed for *client* and *server* authentication.
the client can authenticate with password, keyboard-interactive (a digipass
if they wish) and public-key. I wonder how you can authenticate users on ftps
with public keys.
I find that ssh server public host keys are easier for an end-user to deal
with. At first connection, she looks if it matches the hash the system
administrator gave him, she accepts, and it works. On ftps, either the
certificate was signed by verisign (who does ?) either you must import a
public certificate before connecting (I don't remember of a single ftps
client that was doing that but i'm probably wrong, i did not test them all).
-Sftp only uses one byte stream. That was already said. Some people feel there
is no need for them to encrypt the data stream. It's their choice. I
personnaly don't like that other people see what I am downloading on a server
and I prefer being sure the file I downloaded was not tempered with during
transfer. Today, encryption doesn't cost that much cpu.
Morehover, with its single-stream nature, it's easier to make sftp work with
firewalls, both on client and server sites (I remember my father having to
set up a ftps client for his work, it never worked correctly because of my
firewall blocking active mode and server firewall blocking passive mode).
This is my point about why I'm going to do this project. I'm happy to have
received your feedback. Who knows, maybe i'm going to be a netbsd developer