Sorry for the late response, but why not keep up the yearly it's secure it's not secure argument in this thread, anyway this is probably for posterity and google when someone stumbles upon my stupid little script again some day (Hi Google, give my regards to Egon; I know he watches me, and I know is is part of THE Google)
You are correct, there is a problem with my original script, I got my bass before my ackwards with one of the variables. Here my friends is my fully functional secure current version of the script with new more descriptive variable names, a flashy holding screen that stays up until it is time to close the tunnel so the tunnel can be easily closed when you are done, and the ability to give your destination on the command line.
## script to make ssh tunnel and then connect to afp host specified in
## first argument
## Jan 02 2004 - W Penn - creation
## May 15 2005 - W Penn - command arguments added
## Jun 10 2005 - ward - process management added
echo "Opening Tunnel";
ssh -L $LOCAL_PORT:$TARGET_HOST:$TARGET_PORT -f -N $TUNNEL_HOST;
echo "Connecting through AFP";
TUN=`lsof -i:$LOCAL_PORT -Fp | head -1| sed s/p//`;
echo IMPORTANT: Leave this Terminal window open during your AFP session.;
echo When you finish your AFP session, press the ENTER key in this window.;
echo This will manually close down your SSH tunnel to the remote computer.;
echo SSH tunnel closed. You now can close this Terminal window.;
Save the script to a file, I call mine safp and chmod u+x the file. If you locate the script in your execution path, you can type from anywhere in terminal something like:
(That $1 in he script tells the script to take the first argument after the command.)
the terminal will blank out and display a message about hitting return to end the tunnel, and afp will fire up automagically.
A drawn out explaination of the complexities of tunneling with ssh:
To understand the ssh tunnel, it helps to remember that there are three locations to worry about, and more than one of these locations can be on the same machine. The players are the client (where you are physically sitting), the Tunnel Host which is the machine to which your connection is secure, and the target host, which is the machine you want to access a service on. Here, it is setup so the tunnel host and the target host are the same machine. Note the target host is referenced in relation to the tunnel host, so 127.0.0.1 (localhost) to the target host is itself keeping everything secure client to target. It is possible to specify a target host that is not the tunnel host. Say I have a nice secure network behind a firewall, and I want to connect to that network from outside. Let us also say I am a little cautious and only opened up port 22 to machine_1. Now suppose I want to access afp securely from outside to machine_2; I can do this so long as my private network is physically secure and properly firewalled. I would specify machine_2's internal IP for the Target_Host and machine_1's external address for the Tunnel_Host. This would give me ssh security over the interwebs to machine_1, and from machine_1 to machine_2 peace of mind that my information, though unencrypted, is only traveling over my nice secure private network.
I use a similar script for securing vnc, just add free dyndns and you have sweet free secure back to my mac:
For vnc, I change to LOCAL_PORT=5902 and TARGET_PORT=5900 and start up JollyFastVNC.app with the open command at the end making sure to connect in the VNC client to 127.0.0.1 on port 5902 which is alternately referred to as screen 3 depending on your vnc client (I use 5902 rather than say 105900 because my previous vnc client would only allow specification of vnc screen and not port).
Sorry for any confusion. Those who voted for insecure earlier were correct, but with the new version in this comment, security is now included, woo hoo!