Martin F Krafft wrote:
hi, i operate a couple of non-profit servers for friends to host their websites. there is only ssh, no ftp, but most users are mac or windoze, and so they have considerable difficulty uploading, even with the OpenSSL or other comparable scp-featuring packages. i would like to enable user ftp for them to facilitate, but it's too much of a security risk due to clear text passwords being sent over the wire. so i am wondering what other alternatives there are to allow users easy remote management of their websites, similar to ftp. or is there even an ssh-capable rsync client for mac and windoze, preferably, of course, with a GUI? thanks for any thoughts, martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:"; net@madduck
You could use ssh to create a secure "tunnel" by forwarding ftp connections on the client to the server then configure the ftp software on the client to communicate with localhost and ssh will automatically forward all traffic to the server. Don't forget ftp uses two ports, 20 and 21. Exactly where this forwarding is configured depends on the ssh software being used but I know at least some software for Windows and Mac support this feature. Here is the section from the man page for openssh describing how to set this up. The basic idea is the same for other ssh software.
-L port:host:hostportSpecifies that the given port on the local (client) host is to be forwarded to the given host and port on the remote side. This works by allocating a socket to listen to port on the local side, and whenever a connection is made to this port, the connection is forwarded over the secure channel, and a connection is made to host port hostport from the remote machine. Port forwardings can also be specified in the configuration file. Only root can forward privileged ports.
So, for example, if the remote server is called popserver, my openssh command line to "tunnel" port 110 (POP) would be
ssh -L 110:localhost:110 popserver- the first 110 is the local port to forward from (this could actually be any unused port but, if you can, it's easier to use the standard port for the protocol since some client software won't let you specify an alternative port to use)
- localhost is the destination machine relative to popserver - the second 110 is the port on the destination machine to forward tonow if I type this in another terminal on my local machine (not in the ssh connection I just established)
telnet localhost 110I will get the POP login on popserver and the whole communication between my machine and popserver is encrypted, unlike the standard POP protocol which sends everything in the clear.
I like this method because, other than configuring your applications (one time) to connect to localhost instead of the real server (this works just as well for IMAP, SMTP, etc), this is completely transparent to the client application. You just have to have the ssh software running and connected to the real server with the ports forwarded (most likely in the background - I used to make it a startup item when I had to use those other operating systems).