David, On 16 Jan 1999 you wrote: The problem with having EFS support sftp is that the ssh people haven't implemented a proper FT protocol with return codes. For example: sftp> pwd /home/sandy as opposed to ftp> pwd 257 "/home/sandy" is current directory. EFS relies heavily (in fact almost exclusively) on the numeric codes to determine the success of remote commands and the state of the server. The meanings of these codes is defined in RFC 959 and I wrote the EFS process filter as a strict implementation of this RFC. In my opinion, if people want ssh support in EFS (and I think that a more secure version of FTP would be good), then you should go after the ssh people to make sftp follow RFC 959. Trying to make EFS work with a file transfer server that doesn't follow a rigid protocol is in my opinion a waste of time. The result would be so flakey as to not be worth the trouble. The FT Protocol as defined in RFC 959 is very well designed for robust server-client interaction and the ssh people would do well to use it. BTW, does anybody out there know of other file transfer servers (other than FTP) that follow a tight protocol spec? If so, than EFS support for it might be possible. ...Sandy

Sandy> BTW, does anybody out there know of other file transfer Sandy> servers (other than FTP) that follow a tight protocol spec? Sandy> If so, than EFS support for it might be possible. jam> Long overdue on my to do list is to look at jam> <http://www.docs.uu.se/~pem/hacks/ftpsshd-1.1.tar.gz>;. That jam> reportedly works with ssh-1.2.26 atop Solaris or Linux at jam> least. IIRC it talks to a standard ftpd but through jam> redirected ssh secured channels. A quick look indicates that ftpsshd works as advertised on linux when built with gcc-2.7.2.1 and libc5 with slight obvious adjustments. Normal remote ftp server and local ftp clients are used with both control and data channels redirected through ssh encrypted (and optionally compressed) connections. I found both the ftp client from NetKit-B-0.09 and ncftp-1.9.9e to work for me with no surprises when talking through ftpsshd to a wu-2.4.2-academ[BETA-18] ftp server. ftpsshd is GPLed and might be a candidate to let efs do ssh-1.2.26 secured ftp. ftpsshd itself contains no crypto. A little work would be needed to make ftpsshd portable wherever ssh-1.2.x goes; but it is small, the sources total less than 1,300 lines including comments. Perhaps a portable ftpsshd.el would be doable? Or using the four-letter-p-word? jam

Sandy> From what I've read of the README file for ftpsshd 1.1, it Sandy> should work with EFS as is, or with very minor Sandy> configuration changes. This of course assumes that your Sandy> ssh is using RSA authentication with an empty pass phrase. Sandy> Otherwise, EFS would have to authenticate with the pass Sandy> phrase for every data transfer. Getting EFS to do this Sandy> would require some changes to the code. When using the ssh-agent it should be possible to enter passphrase(s) only once during login session or similar. Using an empty passphrase requires close attention and close control of the operating environment to prevent exploitation. Without ssh-agent a passphrase would be required for each ssh connection, not each ftp connection. Sandy> Has anyone already tried to use ftpsshd with EFS? I don't grok how to tell efs to do the equivalent of ftp localhost 2121 for one non-local connection, and ftp localhost 2122 for another while still being able to connect the old way. The above would be after having previously done something like ftpsshd -C -p2121 host1.dom1.ain ftpsshd -C -p2122 host2.dom2.ain from a shell. This is where ssh passphrase(s) would be called for when not using ssh-agent. All this is assuming that ssh and sshd are optioned 'RSAAuthentication yes' which is usually what is wanted. jam