Article:		Inside SSH, Part 1
Subject:		ssh secure AFP connection with OSX 10.3.4 (not server version) How To
Date:		2006-01-24 17:34:54
From:		wfaulk
Response to: ssh secure AFP connection with OSX 10.3.4 (not server version) How To
This code is 100% insecure. All it does is make a secure connection to the computer you're currently logged into (which is fairly pointless) and then opens an unencrypted tunnel to the remote host. The reason you can specify a host in the -L option is so that you can have an encrypted tunnel through an insecure network to one that is secure, but you can't open an SSH connection to the host you need to tunnel to, so you connect to another host on the remote secure network and it then passes the decrypted data to the other host. What you're doing here is encrypting the data between the localhost and itself, then passing unencrypted data to the remote host as if you'd never used SSH at all. All you're doing is wasting CPU cycles. What you want to do is ssh -L${LOCAL_PORT}:${TARGET_HOST}:${TARGET_PORT} ${TARGET_HOST} This will open an encrypted channel to the remote host, where the data will be unencrypted and sent along to the host and port specified, which, in this case, is the same host doing the decrypting.

Showing messages 1 through 3 of 3.

• NO, This code is *NOT* 100% insecure.
  2006-01-25 23:24:58  GNULinux4me [View]
  
  
  You are wrong when you suggest this code is 100% insecure!
  SSH opens an encrypted session between the SSH client (computer you are sitting at) and the SSH server (remote SSH server.) In most cases, the client and server are separated by at least one firewall, between 2 trusted networks.
  
  When you use the script supplied in the article, the client (computer you are sitting in front of) opens an encrypted SSH session to the target (remote SSH server.)
  
  The -L option tells the SSH client on your workstation to listen for a connection to localhost on port 10548. When the client connects to localhost 10548 after establishing the SSH session, the SSH client forwards the connection through the encrypted SSH tunnel to the target SSH server.
  
  When the target SSH server receives the forwarded port request through the encrypted SSH session, the target SSH server forwards unencrypted traffic destined for 548 to the AFP host (host defined between the listen port and destination port separated by :.
  
  If the remote host accepting the AFP traffic is on the same network as the destination SSH server and behind a firewall, the connection has been secured because the vulnerable traffic was encrypted while in transit over the Internet (between the two trusted networks.)
  
  If you can't trust the destination network, then you shouldn't even connect with SSH.
  
  You may want to do some more research. To test this, block TCP port 548 on your target network, then forward TCP 548 to a destination behind your target network. Connect to localhost on TCP 548 and see that you get a connection. If you do this correctly, you should mount a share on the target network through the SSH tunnel. If you can mount the AFP share via localhost, then you have proven it was through the SSH tunnel because the firewall rule blocks the traffic from the Internet. If the traffic came through the SSH tunnel, it was encrypted between the two networks. This isn't rocket science!
• YES, This code is 100% insecure.
  2007-08-21 01:15:27  macGenius [View]
  
  
  You are right when you are saying that the afp connection is forwarded over ssh... only it's forwarded over ssh to LOCALHOST!
  
  From there on, it's sent via the internet - unencrypted!
  
  So, dear GNULinux4me, maybe you should do this research you were talking about yourself!
  
  
  
• YES, This code is 100% insecure.
  2008-08-30 00:06:55  bill penn [View]
  
  
  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.
  
  --Begin Script--
  #!/bin/sh
  
  ## 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
  ##
  
  LOCAL_PORT=10548;
  
  TARGET_HOST=127.0.0.1;
  TARGET_PORT=548;
  
  TUNNEL_HOST="$1";
  
  echo "Opening Tunnel";
  ssh -L $LOCAL_PORT:$TARGET_HOST:$TARGET_PORT -f -N $TUNNEL_HOST;
  echo "Connecting through AFP";
  open afp://localhost:$LOCAL_PORT/;
  
  clear;
  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.;
  read answer;
  clear;
  kill $TUN;
  echo SSH tunnel closed. You now can close this Terminal window.;
  
  --End Script--
  
  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:
  
  safp somehost.com
  
  (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!