netatalk.io

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:

Footnotes

This is a mirror of the Netatalk GitHub Wiki. Please visit the original page if you want to correct an error or contribute new contents.

Last updated 2025-10-09