This page provides instructions for authenticating with and connecting to systems primarily using SSH-2 methods.
NOTE: ITS supports public key and password-based authentication methods. Users can also authenticate using Kerberos with SSH-1. SSH-2 support for Kerberos will be added once it becomes available. Rhosts-based authentication is not recommended in implementations of SSH-2 due to its inherent security vulnerabilities.
Public Key Authentication
Both a public and a private key are used in public key authentication. The encryption done with the public key can be undone with the private key, and vice versa. The public key can be distributed and made available to everyone, while the private key is only known to the user and is encrypted if stored (using a passphrase. Either of the keys can be used for encryption and decryption. Because of this symmetry, you only need one key to decrypt information encrypted by the other key. The length of the keys and the method of encryption used makes the keys extremely secure.
For the authentication process, the user encrypts a piece of plain text with a private key and sends it to a remote system. The recipient (for SSH, the SSH daemon) uses the user’s locally stored public key to decrypt the encrypted text (ciphertext). If it decrypts properly, the user is authenticated.
In public key authentication, the password for the account is not transmitted at all. You are required to use another passphrase when storing private keys, which should be at least as strong as your password.
Creating Keys for SSH
Before public key authentication can be used, the necessary keys must be created. The command ssh-keygen is used to generate the necessary keys for SSH: DSA, RSA, and RSA1 (for SSH-1).
somehost.usc.edu(1): ssh-keygen -t rsa -f ~ttrojan/.ssh/id_rsa
Generating public/private rsa key pair.
Enter passphrase(empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/somehost-00/ttrojan/.ssh/id_rsa.
Your public key has been saved in /home/somehost-00/ttrojan/.ssh/id_rsa.pub.
The key fingerprint is:
1024 00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff ttrojan@somehost.usc.edu
somehost.usc.edu(2): ssh-keygen -t dsa -f ~ttrojan/.ssh/id_dsa
Generating public/private dsa key pair.
Enter passphrase(empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/somehost-00/ttrojan/.ssh/id_dsa.
Your public key has been saved in /home/somehost-00/ttrojan/.ssh/id_dsa.pub.
The key fingerprint is:
1024 ff:ee:dd:cc:bb:aa:99:88:77:66:55:44:33:22:11:00 ttrojan@somehost.usc.edu
During key creation, users will be prompted for a passphrase for each key. This passphrase is used to encrypt the key when it is stored on the computer. To avoid the possibility of a malicious user connecting to computers that house your public key, your passphrase should be between 10 to 30 characters long and difficult to guess. Your passphrase should not be the same as your password.
While any user can use this command to create their own keys, ITS has provided a script, ssh-user-config, that will generate and automatically place keys in the correct locations for OpenSSH implementation.
The ssh-user-config script will also prompt users on whether to add generated keys to the file ~/.ssh/authorized-keys, which allows users to utilize public key authentication, below. The script will also ask users if they want to start ssh-agent with CDE. This is mainly for users working directly on a console.
Public Key Authentication
Once created, public keys should be distributed to the computers that the user connects to. The ssh-user-config script adds public keys to the ~/.ssh/authorized-keys file (if the user elects to do so), allowing users to connect to systems mounting the same home directory without having to add new hosts. For other accounts or other systems, the public keys will need to be added by the user.
When a user tries to run ssh, the program will look for locally stored private keys: ~/.ssh/id_rsa1 and ~/.ssh/identity (RSA1, SSH-1), ~/.ssh/id_rsa (RSA, SSH-2), and ~/.ssh/id_dsa (DSA, SSH-2). If any exist, the user will be prompted for the passphrase so that they can be decoded and used against the public key stored on the system the user is trying to connect to.
If the decoded private key works properly with the public key stored on the remote system, the user is authenticated and allowed to connect, without having to enter a password:
somehost.usc.edu(1): ssh ttrojan@hostname
Enter passphrase for key '/home/somehost-00/ttrojan/.ssh/id_rsa':
Enter passphrase for key '/home/somehost-00/ttrojan/.ssh/id_dsa':
hostname.usc.edu(1): whoami
ttrojan
In the above example, either the passphrase provided for the RSA key was incorrect, or the RSA public key information did not exist in the authorized-keys file. The passphrase for the DSA key was correct and in the authorized-keys, and the user was properly authenticated and allowed to connect.
SSH attempts to authenticate with the RSA keys first, followed by the DSA keys. If neither key works, public key authentication fails totally, and SSH attempts to use password-based authentication, below:
Instructions: ssh ttrojan@hostname
Enter passphrase for key '/home/somehost-00/ttrojan/.ssh/id_rsa':
Enter passphrase for key '/home/somehost-00/ttrojan/.ssh/id_dsa':
ttrojan@hostname's password:
Using The SSH-Agent
With public key authentication, a passphrase must be provided to decrypt the stored private keys. Fortunately, the ssh-agent is provided, relieving the user from having to enter passphrases every time an ssh connection is needed.
Because the ssh-agent outputs commands to alter the user’s environment, the command must be used with eval to keep the current shell:
somehost.usc.edu(1): eval `ssh-agent`
Agent pid 586
Alternately, a user can start a new shell as a subprocess of the ssh-agent:
somehost.usc.edu(5): ssh-agent $shell
somehost.usc.edu(1):
Once the ssh-agent is started, keys must be explicitly added to it by the user, using the command ssh-add. If no file containing a key is specified, ssh-add will look for keys in the files: ~/.ssh/identity and ~/.ssh/rsa1 (RSA1, SSH-1), ~/.ssh/id_rsa (RSA, SSH-2), and ~/.ssh/id_dsa (DSA, SSH-2).
ssh-add will prompt the user for the appropriate passphrase for each key, as it attempts to decrypt them. The program will attempt to use the same passphrase for each key, prompting the user to re-enter the passphrase if the decryption fails.
To explicitly add keys to the ssh-agent:
somehost.usc.edu(1): ssh-add ~/.ssh/id_dsa
Enter passphrase for /home/somehost-00/ttrojan/.ssh/id_dsa:
Identity added: /home/somehost-00/ttrojan/.ssh/id_dsa (/home/somehost-00/ttrojan/.ssh/id_dsa)
somehost.usc.edu(2): ssh-add ~/.ssh/isd_rsa
Enter passphrase for /home/somehost-00/ttrojan/.ssh/id_rsa:
Identity added: /home/somehost-00/ttrojan/.ssh/id_rsa (/home/somehost-00/ttrojan/.ssh/id_rsa)
After keys are added to the ssh-agent, ssh will use the ssh-agent to supply its stored keys as part of the authentication process, rather than the user supplying the passphrase needed to decrypt the private keys stored locally.
To view keys currently stored in the ssh-agent:
somehost.usc.edu(3): ssh-add -l
1024 00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff /home/somehost-00/ttrojan/.ssh/id_rsa (RSA)
1024 ff:ee:dd:cc:bb:aa:99:88:77:66:55:44:33:22:11:00 /home/somehost-00/ttrojan/.ssh/id_dsa (DSA)
To remove a key from the ssh-agent:
somehost.usc.edu(4): ssh-add -d ~/.ssh/id_rsa
Identity removed: /home/somehost-00/ttrojan/.ssh/id_rsa (/home/somehost-00/ttrojan/.ssh/id_rsa.pub)
somehost.usc.edu(5): ssh-add -l
1024 ff:ee:dd:cc:bb:aa:99:88:77:66:55:44:33:22:11:00 /home/somehost-00/ttrojan/.ssh/id_dsa (DSA)
To remove all keys from the ssh-agent:
somehost.usc.edu(4): ssh-add -D
All identities removed.
somehost.usc.edu(5): ssh-add -l
The agent has no identities.
To stop the ssh-agent:
somehost.usc.edu(6): eval `ssh-agent -k`
Agent pid 586 killed;
If the shell was a subshell of the ssh-agent (started with ssh-agent $shell above), exiting the shell will also terminate the ssh-agent.
The ssh-user-config script adds, if the user elects to, commands to a user’s CDE startup and shutdown scripts to manage the ssh-agent automatically.