Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'AFP over SSH Tunnel' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
AFP over SSH Tunnel
Authored by: comboprime on Mar 02, '07 11:28:52AM
> 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 | # ]
AFP over SSH Tunnel
Authored by: landis on Mar 02, '07 02:24:32PM
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 | # ]

AFP over SSH Tunnel
Authored by: comboprime on Mar 02, '07 04:44:06PM
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 | # ]
AFP over SSH Tunnel
Authored by: jms1 on Mar 02, '07 11:25:57PM

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 | # ]