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:"; [EMAIL PROTECTED]
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:hostport
Specifies 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 to
now if I type this in another terminal on my local machine (not in the
ssh connection I just established)
telnet localhost 110
I 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).
