Re: rssh.el interactions with ange-ftp/efs

Sandy> Also, as I mentioned in an earlier message of mine (that Sandy> went to a smaller recipient list than this one), scp (part Sandy> of ssh-1) and sftp (part of ssh-2) don't follow a Sandy> well-defined protocol, such as defined in RFC 959. EFS Sandy> relies almost exclusively on the 3-digit FTP return codes Sandy> to determine the state of the server and the success or Sandy> failure of commands. Here is an example of what I mean: sftp> pwd Sandy> /home/sandy Sandy> as opposed to ftp> pwd Sandy> 257 "/home/sandy" is current directory. Using ftp through the ssh tunnels set up by ftpsshd does not change the behavior of either the ftp client nor of the ftp server. You see exactly the same result. Sandy> Therefore, any EFS-like program that used scp or sftp Sandy> underneath would likely be quite unreliable. IMHO, writing Sandy> scp support into EFS would be a waste of time. In Sandy> addition, because scp isn't following any published Sandy> protocol, chances are more than likely that you would no Sandy> sooner finish your code, than some bright light at SSH Sandy> would decide to change the output from scp commands for the Sandy> sake of aesthetics. That is why I suggested ftpsshd. You still run plain old ftp but through channels secured by ssh. Also it would seem that since this approach uses only a straight forward application of the port forwarding mechanism of ssh-1.x it should work with little change with successor implementations of the ssh protocol(s) that do port forwarding whether or not they have their own ftp-like facilities. Sandy> I agree with Richard that a free secure file transfer Sandy> program is needed. However, I would add that it should Sandy> also be based on a well-defined and established protocol. Sandy> The FT Protocol defined in RFC 959 is a good starting Sandy> point; although, a case can be made for expanding this Sandy> protocol in some areas. That seems to argue for ftpsshd. jam