SSH on Mac OS X
11th Feb 2003, 08:10:35
Updated 9th December 2008.
SSH is a secure way to connect to your Mac over untrusted networks, such as the Internet. At its most basic level, it allows you to log into a Mac remotely using the terminal using the sshd and ssh programs. You must enable the SSH service on the Mac you want to log in to:
Once you have the service enabled, it's a matter of logging in using the ssh program on the client to connect to the server:
iMac:~ stocksy$ ssh james@194.11.2.81 The authenticity of host '194.11.2.81 (194.11.2.81)' can't be established. RSA key fingerprint is XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '194.11.2.81' (RSA) to the list of known hosts. james@194.11.2.81's password: Last login: Mon Mar 22 21:39:48 2004 Welcome to Darwin! Power-Mac:~ james$
The part about the authenticity of the host is only shown the first time you connect to a Mac, after that it gets added to ~/.ssh/known_hosts
So, now you've got a remote terminal on your other Mac. This is useful. Imagine that the Finder has crashed and frozen the whole GUI on your PowerBook, usually it's still possible to SSH into the machine and kill -9 the 'loginwindow' process. This just reloads the GUI and logs you out without restarting. That said, we can do more...
Passwordless logins with SSH
You can SSH without using a password by generating a private/public key pair. Bear with me! The public key resides on the computer you are connecting to (server) and is compared with your private key on the computer you are connecting from (client).
The keys could be generated anyway, but for this example we will be generating them on the client computer:
$ ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/Users/stocksy/.ssh/id_dsa): Enter passphrase (empty for no passphrase): wxyz Enter same passphrase again: wxyz
The ssh-keygen programme has just created two DSA (-t dsa specifies this) keys on your Mac. id_dsa is the private key and
id_dsa.pub is the public key. You need to copy
the public key, ~/.ssh/id_dsa.pub from the client to ~/.ssh/authorized_keys2 on the server using scp:
scp [source] [user]@[remote.host]:[destination]
For example:
iMac:~ stocksy$ scp ~/.ssh/id_dsa.pub james@194.11.2.81:~/.ssh/authorized_keys2
Important: Only ever copy the public key to other machines. The private key, as the name suggests must be kept secret, so only store it on computers you know are secure.
If you have several clients you want to connect to the server, you'll need to combine all the id_dsa.pub keys from each machine into one authorized_keys2
file. I would suggest that the best way to do this is to copy all the id_dsa.pub files into a temporary directory on the server, so that you have something like
Power-Mac:~/Desktop/ssh jamen$ ls id_dsa.pub.1 id_dsa.2 id_dsa.3
Then, combine them like so:
Power-Mac:~/Desktop/ssh jamen$ cat id_dsa.pub.1 id_dsa.pub.2 id_dsa.pub.3 > authorized_keys2
cp authorized_keys2 ~/.ssh/authorized_keys2
Ok, you're ready to test your keys! Open a fresh terminal on your client and ssh to your server as above. It should ask you for the passphrase you provided for the key rather than the password of you account on the machine. The next step is to use SSHKeychain to hold this passphrase in the Apple Keychain.
Download SSHKeychain, mount the .dmg and drag sshkeychain to /Applications. Run SSHKeychain from the Finder and open its preferences. In the 'general' tab, set it to show in the Status Bar. In the 'security' tab, set 'On client connection' to 'Add keys to agent'. In the 'environment', tick 'Manage global environment variables'. From the menu bar Select 'Agent|Add All Keys'. Enter the passphrase you specified when you did ssh-keygen -t dsa and tick 'Add to keychain'.
Now, add /Applications/SSHKeychain to Login items in System Preferences -> Accounts.
Log out and back in to your account on the client, open a terminal and ssh to your server, it should not ask for a password!
Security
These steps aren't necessary to get ssh working, but they do help to harden your Mac against attack.
By default, you can log in to any account on your Mac, but this can be changed. Use your favourite text editor to open /etc/sshd_config, for example:
sudo nano /etc/sshd_config
Add a line like this:
AllowUsers tom dick harry
Alternatively, you could format the line like this if you know the IPs that require remote access:
AllowUsers tom@194.202.218.1 dick@stocksy.co.uk harry@18.51.1.222
The ssh V1 protocol is not as secure as ssh V2, you can prevent ssh V1 logins by finding this line: #Protocol 2,1 and changing it to:
Protocol 2.
You can insist that all logins must use a public key instead of password authentication, change: #PasswordAuthentication yes
to: PasswordAuthentication no. I find this is especially useful to access family members' computers which I know have horribly
insecure passwords.
It's possible to add a login banner just to cover yourself. Create the banner as a plain text file, e.g. /etc/loginbanner, then add this line:
Banner /etc/loginbanner. An example of an appropriate banner might be:
THIS IS A PRIVATE COMPUTER SYSTEM AND IS FOR AUTHORISED USE ONLY.
Any or all use of this system and all files on this system may be intercepted
and monitored. Unauthorised or improper use of this system may result in
disciplinary and/or legal action. By continuing to use this system you indicate
your awareness of and consent to these terms and conditions of use.
LOG OFF IMMEDIATELY if you are not an authorised user of this system or do not
agree to the conditions stated in this warning.
Do NOT write "Please log in" or some similar form of words that could be interpreted as consent to use the system.
Tunnelling unsecure protocols over ssh
If you're not familiar with it, VNC is a protocol used to view the desktop of a host using another host on a network. VNC is an unencrypted protocol. If you used it 'naked' over the Internet, somebody could sniff the packets and compromise your Mac. What's needed is an ssh tunnel to encrypt the VNC packets as they travel through the internet:
Setting up the tunnel is easy, you just need to know the IP address of the remote host and the port number that VNC is running on (usually 5900). The syntax of the command is:
ssh -L [local port]:127.0.0.1:[remote port] [user]@[remote.host]
So in this case it would be:
ssh -L 5900:127.0.0.1:5900 james@194.11.2.81
All you need to do now is point your VNC client to 127.0.0.1:5900 and you can connect. If you wanted to allow other machines on your local network to access the remote host through your computer, use the -g switch:
ssh -L 5900:127.0.0.1:5900 -g james@194.11.2.81
Then other hosts on your network can connect to the remote host through [your.IP]:5900, just remember to open this port on your firewall.
I would suggest using OSXvnc as your VNC Server and Chicken of the VNC as your VNC client.
Forwarding file sharing over SSH
It's easy to encrypt Apple file sharing with SSH. The syntax is the same as it was for VNC:
ssh -L [local port]:127.0.0.1:[remote port] [user]@[remote.host]
Apple file sharing works on port 548, so in my case the command would be:
ssh -L 54854:127.0.0.1:548 james@194.11.2.81
So, your local machine is now serving your remote machine's files on 127.0.0.1:54854, go ahead and test it: In the finder, click 'Go|Connect to server' and type in afp://127.0.0.1:54854 - this should connect you to the remote Mac. As before, if you want your local Mac to act as a gateway to the remote Mac, use the -g switch and connect to afp://your.ip:54854 from the other Macs, but remember to open port 54854 on your local Mac.
It is vital to use a port such as 54854, since Personal File Sharing may have already bound port 548 on your machine, which will cause an error message.
One More
One last commonly used example, MySQL.
ssh -L 3306:127.0.0.1:3306 james@194.11.2.81
Now you can point a GUI like Sequel Pro at 127.0.0.1 port 3306 and work on your remote MySQL server.
Tunneling your Browsing
If you are connected to an untrusted network it would be desirable to encrypt and tunnel your machine's traffic to a trusted machine elsewhere. SSH can do this by acting as a SOCKS proxy by using the -D (dynamic) option:
ssh -D3333 james@192.2.0.22
Once this is done, configure your favourite browser to use 127.0.0.1 port 3333 as a SOCKS 5 proxy:
All web traffic is now sent through the tunnel to your remote machine before being decrypted and forwarded to the final destination. Note that whilst your web traffic is secured, your machine might still be sending DNS queries to the local DNS server. This could allow a third party on the untrusted network to determine which sites you've visited, but not read any information you've transmitted or received.
More Tricks
If you're on a low bandwidth connection, using the -C option enables compression which might help speed things up a bit.
If you have X11 installed, you can use the -Y option to display X11 applications from a remote machine on your own desktop. This is most useful when dealing with a remote Linux or UNIX box:
ssh -Y james@10.1.55.17 firefox &
would launch Firefox on the remote machine, but display the application locally.
Further Reading
If you want a more flexible solution, take a look at my page about OpenVPN.
1 Archived Comment
6th Dec 2009, 09:00:02 by cronky
Nice article - thanks - just tweeted about it http://twitter.com/cronky/status/6395657733