Archive for February, 2011

Understanding SSH

February 6, 2011

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:

  1. 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.
  2. The two computers use the public keys to negotiate a session key used to encrypt subsequent session data.
  3. 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.
  4. 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:

  1. A private and a public key are generated, each associated with a user name to establish that user’s authenticity.
  2. When you attempt to log in as that user, the user name is sent to the remote computer.
  3. 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.
  4. A challenge is sent to the user based on his or her public key.
  5. The user verifies his or her identity by using the private portion of the key pair to decode the challenge.
  6. 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.