|
|
> It appears there is a clear lack here : no correct sftp server and no
> correct sftp client.
...?? What's "incorrect" about the existing ones?
> [...], because there are more than one socket stream involved (and
> it's completely useless to protect the "command" socket without
> protecting the "data" socket).
I disagree. There are plenty of cases where you don't care about
protecting the data being transferred but you're not about to send a
password (as is required for traditional non-anonymous FTP) in the
clear. I do such transfers regularly (though not through either ftp or
sftp; I usually do them with an interactive ssh login and plus netcat).
But you're right if you mean that a general-purpose replacement needs
to protect the data stream as well as the command stream.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse@xxxxxxxxxxxxxxxxxxxxxx
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
|
|