SSH Tunneling

AFP SSH tunneling

Until circa Mac OS X 10.6, Apple provided an option called "Allow Secure Connections Using SSH" when mounting an AFP volume.

As it might be challenging to configure a modern SSH server to accept the ancient cryptography of 90s and 00s Mac clients, this feature is likely relevant only when combining retro AFP hosts and clients.

Manually tunneling an AFP session

This works since the first AFP servers that spoke "AFP over TCP" appeared in networks. One simply tunnels the remote server's AFP port to a local port different than 548 and connects locally to this port afterwards. On macOS this can be done by

ssh -l $USER $SERVER -L 10548:127.0.0.1:548 sleep 3000

After establishing the tunnel one will use "afp://127.0.0.1:10548" in the "Connect to server" dialog. All AFP traffic including the initial connection attempts will be sent encrypted over the wire since the local AFP client will connect to the Mac's local port 10548 which will be forwarded to the remote server's AFP port (we used the default 548) over SSH.

This sort of tunnel is an ideal solution if you must access an AFP server through the Internet without having the ability or desire to use a "real" VPN. Note that you can let ssh compress the data by using its "-C" switch and that the tunnel endpoints can be different from both AFP client and server (compare with the SSH documentation for details).

Automatically establishing a tunneled AFP connection

From Mac OS X 10.2 to 10.4, Apple added an "Allow Secure Connections Using SSH" checkbox to the "Connect to Server" dialog. The idea behind this was: When the server signals that it can be contacted by SSH then macOS's AFP client tries to establish the tunnel and automagically send all AFP traffic through it.

But it took until the release of Mac OS X 10.3 that this feature worked the first time... partly. In case, the SSH tunnel could not be established and the AFP client silently fell back to an unencrypted AFP connection attempt.

Netatalk's afpd will report that it is capable of handling SSH tunneled AFP requests, when both "advertise ssh" and "fqdn" options are set in the Global section (double check with asip-status after you restarted afpd when you made changes to the settings). But there are a couple of reasons why you don't want to use this option at all:

• Most users who need such a feature are probably already familiar with using a VPN; it might be easier for the user to employ the same VPN software in order to connect to the network on which the AFP server is running, and then to access the AFP server as normal.

  That being said, for the simple case of connecting to one specific AFP server, a direct SSH connection is likely to perform better than a general-purpose VPN; contrary to popular belief, tunneling via SSH does not result in what's called "TCP-over-TCP meltdown", because the AFP data that are being tunneled do not encapsulate TCP data.

• Since this SSH kludge isn't a normal UAM that integrates directly into the AFP authentication mechanisms but instead uses a single flag signalling clients whether they can try to establish a tunnel or not, it makes life harder to see what's happening when things go wrong.

• You cannot control which machines are logged on by Netatalk tools like a macusers since all connection attempts seem to be made from localhost.

• Indeed, to ensure that all AFP sessions are encrypted via SSH, you need to limit afpd to connections that originate only from localhost (e.g., by using Wietse Venema's TCP Wrappers, or by using suitable firewall or packet-filtering facilities, etc.).

  Otherwise, when you're using Mac OS X 10.2 through 10.3.3, you get the opposite of what you'd expect: potentially unencrypted AFP communications (including login credentials) being sent across the network without a single notification that establishing the tunnel failed. Apple fixed that with Mac OS X 10.3.4.

• Encrypting all AFP sessions via SSH can lead to a significantly higher load on the computer that is running the AFP server, because that computer must also handle encryption; if the user is connecting through a trusted network, then such encryption might be an unnecessary overhead.