I used to do that. . . . Turn on Personal File Sharing, or AFP--Apple File Protocol, I think--on my home server, then easily mount it on my laptop wherever I was. More recently, I've come to the impression that AFP is very insecure.

Instead, I turned off AFP and turned on SSH. I configured SSH to *not* allow password authentication and only accept public key/DSA passphrase. Then I use SSH Agent [link:]http://www.phil.uu.nl/~xges/ssh/ to create an SSH tunnel before creating an AFP connection inside that.

I'm not an expert, so someone may have even better advice. This adds an extra step, but I believe it's much more secure.

[ Reply to This | # ]

You can also use this technique to connect to Windows servers running either the SMB or CIFS protocols. I routinely use this to connect to servers at work from my Mac.

[ Reply to This | # ]

Any links to some explicit directions on how to do this? I've been using AFP routinely to connect to my home computer with a dyndns domain. I'd much appreciate making this more secure, but never have had luck figuring out the SSH method on my own. I need a hand to hold.... :(

[ Reply to This | # ]

> Any links to some explicit directions on how to do this?

First off, I should clarify my above comment: AFP is turned off at the *router*, not on my home server.

Set up is:

1) On home server's System Preferences > Sharing, turn on "Personal File Sharing" (aka Apple File Protocol, or AFP) and "Remote Login" (aka Secure SHell, or SSH). The firewall should automatically allow these connections, but it doesn't hurt to verify.

2) On your home server, open /etc/sshd_config and make the changes outlined here [link:]http://macdevcenter.com/pub/a/mac/2004/07/20/inside_ssh_pt3.html (basically turning off password authentication, root access, etc.).

3) On home router, disable AFP port forwarding. Computers outside the LAN will not be able to connect to your home server via AFP. (Inside will still work if you use the LAN IP, for example, Go To Server > afp://192.168.0.2.)

4) On home router, enable SSH port forwarding to the server.

5) Generate a public key for your remote computer. There's a great article here [link:]http://www-128.ibm.com/developerworks/library/l-keyc.html but be warned that it's long. Open Terminal and enter ssh-keygen -t dsa. When it asks for a passphrase, enter a really secure one. Accept the default file locations.

6) Add your remote computer's public key to your home server. The public key is a file in a hidden folder of your user directory: ~/.ssh/id_dsa.pub (note the period before ssh). Copy its contents (the key), and paste into your home server's ~/.ssh/authorized_keys file (create if necessary). More info here [link:]http://kimmo.suominen.com/docs/ssh/

6) Get SSH Agent [link:]http://www.phil.uu.nl/~xges/ssh/ and install. Create a DSA identity and set it to be the Default. Select File > New Tunnel and fill in Local Port:10548, user:your-user-name-on-server, Tunnel Host:server-ip-address, Tunnel Port:22, Remote Host:127.0.0.1, Remote Port:548. Click File > Save, and save with a name like "AFP Tunnel."

7) When you're ready to connect, double-click the AFP Tunnel file to open SSH Agent. Enter your passphrase when requested--if you leave the SSH Agent running, you'll only have to enter it once no matter how often you connect or disconnect. Click "Open" in the SSH Agent dialog to start the tunnel.

8) Switch to the Finder and hit Cmd+K (or select Go > Connect to Server). For Server Address, enter afp://localhost:10548. Save it to your favorites, hit Enter, and you're in! (Hopefully.)

Apparently I don't understand how to use BB code tags. Sorry about that.

[ Reply to This | # ]

Now this should definitely be a standalone hint. Thank you so much!

I could still use a little more help tho. I've gone through the steps and can't get it to work. To check things I tried to SSH from my laptop (REMOTE) to my desktop (SERVER) going through the dyndns URL. This is what keeps popping up on the laptop:


REMOTE:~ landis$ ssh landis@server.dyndns.net
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: POSSIBLE DNS SPOOFING DETECTED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The RSA host key for server.dyndns.net has changed,
and the key for the according IP address xx.xxx.xxx.xxx
is unknown. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
LONG KEY STRING REDACTED.
Please contact your system administrator.
Add correct host key in /Users/landis/.ssh/known_hosts to get rid of this message.
Offending key in /Users/landis/.ssh/known_hosts:1
RSA host key for server.dyndns.net has changed and you have requested strict checking.
Host key verification failed.

Items in italics have been changed to avoid posting anything I shouldn't.

Any ideas?

[ Reply to This | # ]

Hmmm . . . not sure exactly what's going on, but the culprit seems to be these lines:

Add correct host key in /Users/landis/.ssh/known_hosts to get rid of this message.
Offending key in /Users/landis/.ssh/known_hosts:1

See explanation here [link:]http://amath.colorado.edu/computing/unix/sshknownhosts.html

[ Reply to This | # ]

two things are going on.

first, the "host key" for your server (the machine you're trying to connect TO) has changed. this can happen if the machine's OS had been re-installed since the last time you ssh'd into it from this client machine, or if the host key was explicitly changed for some reason.

second, the IP address of your server has changed. if the server doesn't have a static IP (which i suspect is the case, because of the "dyndns" name) then this is to be expected.

if possible, watch the logs on the server while trying to ssh into it from this client. when you issue the ssh command on the client, the server's log file should show an incoming ssh connection from the client's IP address. if it doesn't show this but the client is still getting a response from "something", then either you're looking at the wrong log file, or sshd's logging on the server was disabled somehow, or you are indeed connecting to the wrong server (which is the danger it's trying to warn you about.)

as a testing option, you may want to issue the ssh command using the server's IP address instead of the name, after verifying the server's IP address through other means. this way you can be sure that there are no DNS issues which may be causing problems (like somebody hacking the dyndns servers to make your server's name point to the wrong IP address.)

[ Reply to This | # ]

This works for "ftp://"; servers as well.

Am I right in thinking that I can't really use this hint if my home Macs connect to my ISP using DHCP, so my home IP address isn't static? (Plus there an Airport Extreme with NAT turned on, and no ports are forwarded to any of my Macs.)

On the plus side, I think this makes me a bit more secure. This will motivate me to disable the root user when I'm not actually using it!

I suppose I could always write a Mail.app rule and an AppleScript to email me the current home IP address.


[ Reply to This | # ]

Have a look at http://dyndns.org

This will help with the dynamic ip issue.

[ Reply to This | # ]

I have a dynamic IP, but my ISP gives me a static text URL that I can always use to connect to the computer. (I don't know if every ISP does this.) You can find this URL in one of the sharing panes in Sys Prefs, near where you can find your IP address.

If you have this, then you can use it with the "connect to server" command, and also with SSH, FTP, Rsync, etc. It's as good as a static IP address, even when the IP address underlying it is dynamic.

BUT: while you can serve web pages from that URL, as far as I know if you want to register a domain, the new domain must be attached to a real IP address, which means you have to use DynDNS or NoIP or the like.

AND: while I called it 'static,' it's not really. If my cable modem loses its connection and must be reset, then it will create a new URL. But as long as the connection stays up it will effectively be static (mine's been the same for over two years now).

(Hmm, this might be a good hint all on its own...)

[ Reply to This | # ]

One nice bonus of remote disk mounting (as long as the remote host network upload speed is reasonably fast) is to listen to your itunes library remotely.

[ Reply to This | # ]

Great hint! I have used a modification of a prior hint to tunnel Connect to server (Command - K) via SSH for a while.
Also by disallowing password access for SSH and using a ssh-key along with SSH-agent.
It is very secure, as even though i have personal file sharing turned on my 'server', it is behind NAT with port forwarding only for SSH over a non-standard port (ie 3022 rather than the standard 22).

After creaing the tunnel via SSH in the terminal using:
ssh -L 1548:127.0.0.1:548 server_name

I then Connect to server (Command -K) and point to
127.0.0.1:1548

Thus mounting the remote Volumes in the finder.

Thanks rob for this great site!

[ Reply to This | # ]

i just use HamachiX. Really simple, secure and works through firewalls / NAT traversal. Doesn't get much easier. I use it a lot with remote desktop to vnc onto other macs. Enjoy, Jay

[ Reply to This | # ]

I'm new to server and I'm currently setting up one. I'm setting up a 10.5.6 os x mac server and currently its up and running. The only problem is that when I try to connect to the server through its IP that I got from http://www.ipchicken.com or any other IP tracker site it says that it can't connect just like the server din't exist. I have no idea of what I'm going to do. I've heard about Hamatchi but I can't use it since I need the ability to have screen shearing to start and stop programs that the server shall run.

[ Reply to This | # ]