SSH lets you send secure, encrypted commands to a computer remotely, as if you were sitting at the computer. You use the ssh tool in Terminal to open a command-line connection to a remote computer. While the connection is open, commands you enter are performed on the remote computer.
Note: If the SSH service ( sshd daemon ) is enabled you can use any application that supports SSH to connect to a computer running Mac OS X or Mac OS X Server.
How SSH Works
SSH works by setting up encrypted tunnels using public and private keys. Here is a description of an SSH session:
- The local and remote computers exchange public keys. If the local computer has never encountered a given public key, SSH and your web browser prompt you whether to accept the unknown key.
- The two computers use the public keys to negotiate a session key used to encrypt subsequent session data.
- The remote computer attempts to authenticate the local computer using RSA or DSA certificates. If this is not possible, the local computer is prompted for a standard user-name/password combination.
- After successful authentication, the session begins and remote shell, a secure file transfer, a remote command, or other action is begun through the encrypted tunnel.
The following are SSH tools:
- sshd—Daemon that acts as a server to all other commands
- ssh—Primary user tool that includes a remote shell, remote command, and port-
- forwarding sessions
- scp—Secure copy, a tool for automated file transfers
- sftp—Secure FTP, a replacement for FTP
Generating Key Pairs for Key-Based SSH Connections
By default, SSH supports the use of password, key, and Kerberos authentication. The standard method of SSH authentication is to supply login credentials in the form of a user name and password. Identity key pair authentication enables you to log in to the server without supplying a password.
Key-based authentication is more secure than password authentication because it requires that you have the private key file and know the password that lets you access that key file. Password authentication can be compromised without a private key file.
This process works as follows:
- A private and a public key are generated, each associated with a user name to establish that user’s authenticity.
- When you attempt to log in as that user, the user name is sent to the remote computer.
- The remote computer looks in the user’s .ssh/ folder for the user’s public key. This folder is created after using SSH the first time.
- A challenge is sent to the user based on his or her public key.
- The user verifies his or her identity by using the private portion of the key pair to decode the challenge.
- After the key is decoded, the user is logged in without the need for a password. This is especially useful when automating remote scripts.
Note: If the server uses FileVault to encrypt the home folder of the user you want to use SSH to connect as, you must be logged in on the server to use SSH. Alternatively, you can store the keys for the user in a location that is not protected by FileVault, but this is not secure.
To generate the identity key pair:
- Enter the following command on the local computer:
$ ssh-keygen -t dsa
- When prompted, enter a filename in the user’s folder to save the keys in; then enter a password followed by password verification (empty for no password).For example:
Generating public/private dsa key pair. Enter file in which to save the key (/Users/anne/.ssh/id_dsa): frog Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in frog. Your public key has been saved in frog.pub. The key fingerprint is: 4a:5c:6e:9f:3e:35:8b:e5:c9:5a:ac:00:e6:b8:d7:96 annejohnson1@mac.com
This creates two files. Your identification or private key is saved in one file (frog in our example) and your public key is saved in the other (frog.pub in our example).
The key fingerprint, which is derived cryptographically from the public key value, also appears. This secures the public key, making it computationally infeasible for duplication.
- Copy the resulting public file, which contains the local computer’s public key, to the .ssh/authorized_keys file in the user’s home folder on the remote computer (~/.ssh/ authorized_keys).
- The next time you log in to the remote computer from the local computer you won’t need to enter a password.
Note: If you are using an Open Directory user account and have logged in using the account, you do not need to supply a password for SSH login. On Mac OS X Server computers, SSH uses Kerberos for single sign-on authentication with any user account that has an Open Directory password. (Kerberos must be running on the Open Directory server.) For more information, see Open Directory Administration.
Updating SSH Key Fingerprints
The first time you connect to a remote computer using SSH, the local computer prompts for permission to add the remote computer’s fingerprint (or encrypted public key) to a list of known remote computers. You might see a message like this:
The authenticity of host "server1.example.com" can’t be established. RSA key fingerprint is a8:0d:27:63:74:f1:ad:bd:6a:e4:0d:a3:47:a8:f7. Are you sure you want to continue connecting (yes/no)?
The first time you connect, you have no way of knowing whether this is the correct host key. Most people respond “yes.” The host key is then inserted into the ~/.ssh/ known_hosts file so it can be verified in later sessions.
Be sure this is the correct key before accepting it. If possible, provide users with the encryption key through FTP, mail, or a download from the web, so they can be sure of the identity of the server.
If you later see a warning message about a man-in-the-middle attack (see below) when you try to connect, it might be because the key on the remote computer no longer matches the key stored on the local computer. This can happen if you:
Change your SSH configuration on the local or remote computer.
Perform a clean installation of the server software on the computer you are attempting to log in to using SSH.
StartupfromaMacOSXServerCDonthecomputeryouareattemptingtologinto using SSH.
AttempttouseSSHtoaccessacomputerthathasthesameIPaddressasacomputer that you used SSH with on another network.
To connect again, delete the entries corresponding to the remote computer (which can be stored by name and IP address) in the file ~/.ssh/known_hosts.
An SSH Man-in-the-Middle Attack
Sometimes an attacker can access your network and compromise routing information, so that packets intended for a remote computer are routed to the attacker, who then impersonates the remote computer to the local computer and the local computer to the remote computer.
Here’s a typical scenario: A user connects to the remote computer using SSH. By means of spoofing techniques, the attacker poses as the remote computer and receives information from the local computer. The attacker then relays the information to the intended remote computer, receives a response, and then relays the remote computer’s response to the local computer.
Throughout the process, the attacker is privy to all information that goes back and forth, and can modify it.
A sign that can indicate a man-in-the-middle attack is the following message that appears when connecting to the remote computer using SSH.
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
Protect for this type of attack by verifying that the host key sent back is the correct host key for the computer you are trying to reach. Be watchful for the warning message, and alert your users to its meaning.
Important: Removing an entry from the known_hosts file bypasses a security mechanism that would help you avoid imposters and man-in-the-middle attacks. Before you delete its entry from the known_hosts file, be sure you understand why the key on the remote computer has changed.
Connecting to a remote computer using SSH
Use the ssh tool to create a secure shell connection to a remote computer. To access a remote computer using ssh:
- Open Terminal.
- Log in to the remote computer by entering the following command:
$ ssh -l username server Replace username with the name of an administrator user on the remote computer.
Replace server with the name or IP address of the remote computer. For example:
$ ssh -l anne 10.0.1.2
If this is the first time you’ve connected to the remote computer, you’re prompted to continue connecting after the remote computer’s RSA fingerprint appears.
- Enter yes.
- When prompted, enter the user’s password for the remote computer.
The command prompt changes to show that you’re connected to the remote computer. In the case of the previous example, the prompt might look like this:
10.0.1.2:~ anne$
- To send a command to the remote computer, enter the command.
- To close a remote connection, enter logout.
You can authenticate and send a command using a single line by appending the command to execute to the basic ssh tool. For example, to delete a file you could use:
$ ssh -l anne server1.example.com rm /Users/anne/Documents/report
or
$ ssh -l anne@server1.example.com “rm /Users/anne/Documents/report”
You’re prompted for the user’s password.
Reference:
Mac OS X Server (v10.3 or Later): Command-Line Administration (Manual) manuals.info.apple.com p. 31 – 35
