Article:		Inside SSH, Part 1
Subject:		ssh secure AFP connection with OSX 10.3.4 (not server version) How To
Date:		2004-07-12 12:09:34
From:		billpenn
Response to: ssh secure AFP connection with OSX 10.3.4 (not server version)
In order to AFP over an SSH tunnel , you first need to make an SSH tunnel and then you need to connect through that tunnel. I made a script to do this (I know it does no error checking, bad me). Here it is: --Start Code-- #!/bin/sh # script to make ssh tunnel and then connect to afp host # # Jan 02 2004 - W Penn - creation # LOCAL_PORT=10548; LOCAL_HOST=127.0.0.1; TARGET_PORT=548; TARGET_HOST=xxx.xxx.xxx.xxx; ssh -L $LOCAL_PORT:$TARGET_HOST:$TARGET_PORT -f -N $LOCAL_HOST; open afp://localhost:$LOCAL_PORT/; --end code-- You need to enter the host you want to connect to instead of "xxx.xxx.xxx.xxx" for the TARGET_HOST variable. You must be able to log in via afp, and remote login to TARGET_HOST. When run depending on how your are authenticating to TARGET_HOST your remote login password may be requested, then the open command will bring up the afp login window directed to TARGET_HOST. The script makes a secure/encrypted connection from the local machine to the TARGET_HOST's AFP port 548. Then the script tries to open an AFP connection over the secure connection. If you try to connect directly with “connect to server” please note that typing in the IP of your AFP server will not give you a secure connection even after opening the tunnel; instead, you must connect to the local end of the secure connection which from the script is localhost:10548. This is a little weird to the novice as you tell AFP to connect to the local machine in order to REALLY connect to your remote machine. NOTE on firewalls: (1) you do NOT need to open up port 10548 on either machine. (2) You only need port 22 open in a non built in firewall between the two machines (like in a NAT router). (3) AFP and remote login must be turned on on the target in the sharing pref pane. EXTRA NOTE: If you use this, you are using it because you are concerned about security, so you should not use it unless you understand what every “-” “/” “;” “a-z” “A-Z” etc means. You may find searching for "ssh tunnel" on mac OSX hints useful

Showing messages 1 through 9 of 9.

• ssh secure AFP connection with OSX 10.3.4 (not server version) How To
  2006-01-24 17:34:54  wfaulk [View]
  
  
  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.
• 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!
  
  

• ssh secure AFP connection with OSX 10.3.4 (not server version) How To
  2004-07-13 05:57:08  Felix-fi [View]
  
  
  May be I was too optimist... I could not get it to work... despite the fact that I can ssh to the server and AFP is running on it.
  
  It seems to hang at the authentification stage...
  
  Why do not you start the tunnel on the remote host?
• ssh secure AFP connection with OSX 10.3.4 (not server version) How To
  2004-09-10 21:30:17  Syzygies [View]
  
  
  O'Reilly's own book, "SSH, The Secure Shell: The Definitive Guide" is emphatic, one should use localhost if possible here. And no one should attempt a couple of lines of Unix voodoo before reading and understanding a chapter of such a reference.
  
  Of course, I thought I'd just try a line on the web like this, THEN read the chapter to understand what I'd did. I only made it to the chapter after nothing worked. What then worked in an instant was
  
  ssh -L2001:localhost:548 me@$REMOTEHOST
  
  Lesson here, no free lunch, we're the blind leading the blind here until we RTFM.
• ssh secure AFP connection with OSX 10.3.4 (not server version) How To
  2004-10-21 00:12:55  richardwinkel [View]
  
  
  I'm sorry, I'm STILL having problems with this. I've run:
  ssh -L 548:localhost:548 -f -N remote_user@remote.afp.host.com
  
  then I try:
  mount_afp afp://remote_user@localhost/Homes /mnt
  (after I create the directory /mnt)
  
  I get:
  mount_afp: the mount flags are 0000 the altflags are 0020
  mount_afp: AFPMountURL returned error -5019, errno is 17
  
  and nothing is mounted.
  I also tried using the finder's "Connect to server" menu option and it insists I don't really
  want to afp connect to the localhost ...
  
  Thanks for any help!
  
• ssh secure AFP connection with OSX 10.3.4 (not server version) How To
  2005-02-28 01:36:41  sirpete@iki.fi [View]
  
  
  I recommend using different port on localhost. Try ssh -L 10548:localhost:548 -f -N remote_user@remote.afp.host.com
  
  and
  
  mount_afp afp://remote_user@localhost:10548/Homes /mnt
  
  also use the port number if you connect from finder.
  
  Hope this helps.
  
  -Pete

• ssh secure AFP connection with OSX 10.3.4 (not server version) How To
  2004-07-13 05:15:58  Felix-fi [View]
  
  
  Thanks a lot. This solution would work indeed (I use it all the time to tunnel imap and smtp to the servers at work). I can see one drawback is that if you want to do that on more than one machine, you would need to use a new local port for each.
  
  Still, I was wondering if there was a trick to reestablish the "server" ssh-afp feature on a non server OSX. (such as advertising a particular port on the afp server ;-) x being used for basic AFP and y for ssh-AFP)
  
  Thanks again,