Re: UTF8 in SFTP (was: solving the SFTP text mode issue)

[Simon Tatham <anakin%pobox.com@localhost>]

Howard Chu <hyc%highlandsun.com@localhost> wrote:
> SSH itself is a multi-channel protocol. I don't see the problem in
> mapping FTP PORT commands to SSH channels.

Mapping them how? By changing their syntax so that they show SSH
channel numbers rather than IP addresses and ports, or by having the
client somehow translate them _into_ IP addresses and ports, or
what?

A technique that is already practised is to forward an FTP control
channel over SSH, and to edit the PORT commands as they go down the
wire so that the FTP client ends up conducting a multi-connection
FTP dialogue with the SSH client, and the SSH server conducts a
different one with the FTP server. This works, but it's hardly what
I'd call elegant. Particularly since, after you've gone to the
effort of setting up SSH identity keys and arranging one-touch
authentication, the last thing you want is to have to type your
password into an FTP client every time you want to transfer a file!

An alternative would be to have a specialist FTP client integrated
with an SSH server; so that it would send a PASV command and then
ask the SSH server to open a fresh channel to the IP and port number
specified by the FTP server. This would work (modulo the above
authentication inconvenience) but suddenly no existing FTP client is
competent to do this - and what was the point of keeping FTP
unmodified if not to be able to use the large array of existing
clients?

I really don't see why people are still trying to tell us FTP is
perfectly sufficient. SFTP allows plausible automated clients, is
able to run over an already-authenticated SSH connection, and is
readily extensible by a well-defined means. Why, merely because FTP
has solved one or two problems that SFTP as yet hasn't, are people
exhorting us to go back to FTP which fails to solve all those
_other_ problems? I just don't see it.
-- 
Simon Tatham         "Imagine what the world would be like if
<anakin%pobox.com@localhost>    there were no hypothetical situations..."