FAQ | Frequently Asked Questions

brought to you by your friendly
UC Davis Geology Department Computing Support Team

Q: How do I use SSH key pairs to log in to a remote system?
A: The section below covers one way to use SSH key pairs to log in to a remote system?

SSH public-private key logins

In addition to the standard method of user authentication—a username and password—SSH provides another method: public key authentication. With the traditioal authentication method, the remote host stores a username and password pair for a user. With public key authentication, the user creates a key pair on a given host. The key pair consists of of public key and a private key that is protected by a passphrase. Then the user transfers the public key to the remote host to which she would like to connect. So the remote host stores a set of public keys for machines on which you have generated a key pair and and transferred a copy of your public key. [1]

NOTE: This proceedure [2] assumes you have not yet generated an SSH key.

Generate A Key Pair

You will generate a key pair on the host from which you want to access another host. For example, call the system from which you want to connect the local system, and the system to which you want to connect the remote system.

First, in a Terminal window on the local system, make a key pair. Create the key pair using rsa as the key type and 2048 as the bits-size to ensure that you will be connecting via the more secure SSH2 protocol. To generate the key pair type the following command:

  ssh-keygen -b 2048 -t rsa

You will be prompted for a filename; press the RETURN key to accept the default. You will then be prompted for a key passphrase. This key passphrase is used to protect and access your private key. Make sure it is a strong passphrase. Enter it now.

Now you will have your new public-private key set in your   ~/.ssh directory.

The private key is named id_rsa, and the public key is id_rsa.pub. For the remote system to use the key you must copy your public key to the remote system.

Copy The Public Key To The Remote System

If keys have not been used for authentication up to this point, you can simply copy the key to the remote system and rename it. You may need to first create the .ssh directory on the remote system by sending the command: 'mkdir ~/.ssh'

  ssh username@remotehost 'mkdir ~/.ssh'

  scp ~/.ssh/id_rsa.pub   username@remotehost:~/.ssh/authorized_keys

  scp ~/.ssh/2011-may.pub   sadmin@gelremote.ucdavis.edu:~/.ssh/authorized_keys

SSH and SCP will each prompt you for your remote system password. This should be the last time you are ever prompted by the remote system for this password.

The above step will create or replace your keys on the remote server.

If you have authorized keys already, you should append the key to the file like so:

  cat ~/.ssh/id_rsa.pub | ssh username@remotehost 'cat - >> ~/.ssh/authorized_keys'

cat ~/.ssh/2011-may.pub | ssh sadmin@gelremote.ucdavis.edu 'cat - >> ~/.ssh/authorized_keys'

cat ~/.ssh/both_auth_keys | ssh sadmin@gelremote.ucdavis.edu 'cat - >> ~/.ssh/authorized_keys'

SCP will prompt you for your remote system password. This should be the last time you are ever prompted by the remote system for this password.

The above step will append your keys on the remote server.

Now try logging in to the SSH server as you would normally:

  ssh username@remotehost

You will be prompted for your local key passphrase, but not the remote login passphrase.

Disabling Password-based Logins

Once public keys have been installed for all the users who need access to the remote system, normal password-based logins can be disabled on the remote host by editing the /etc/sshd_config or /etc/ssh/sshd_config file and setting:

   PasswordAuthentication no 
you may also need to set:
   ChallengeResponseAuthentication no 
Then restart sshd with a command similar to:
   /usr/bin/sudo /usr/bin/killall -HUP sshd

If killall returns an error message of “No matching processes were found” then you can use the ps command to get the Process ID of sshd and use the kill command:
   $ /usr/bin/sudo /bin/ps -ef | /usr/bin/grep sshd
       0 51613     1   0   0:00.04 ??         0:00.12 /usr/sbin/sshd -i
     501 51616 51613   0   0:00.04 ??         0:00.06 /usr/sbin/sshd -i
     501 52903 51617   0   0:00.00 ttys000    0:00.01 /usr/bin/grep sshd
   $ /usr/bin/sudo /usr/bin/kill -HUP 51613  

but substitute the process ID of the sshd process on your system in place of 51613 (Use the process ID from the line that begins with a zero in the first column, the UID column.)

SSH Best Practices

Caveat:Many of the suggestions for best practices are not necessary with certificate-only logins, and of the rest many are much less useful when you are sure the person trying to login has the private key for the public key you have on file.” — Bill

So if you choose NOT to configure your SSH server only to allow public-private key logins, and to continue to allow password-based logins, then please pay close heed to the following list.

Top 20 OpenSSSH Server Best Security Practices

  • Disable OpenSSH Server unless you need it
  • Only use SSH Protocol 2
  • Limit Users’ SSH Access
  • Configure Idle Log Out Timeout Interval
  • Disable .rhosts Files
  • Disable Host-Based Authenticaiton
  • Disable root Login via SSH
  • Enable a Warning Banner
  • Firewall SSH port 22
  • Change SSH Port and Limit IP Binding
  • Use Strong SSH Passwords and Passphrase
  • Use Public Key Based Authentication
  • Use Keychain based authentication
  • Chroot SSHD (Lock Down User to Their Home Directories)
  • Use TCP Wrappers
  • Disable empty Passwords
  • Thwart SSH Crackers (Brute Force Attack)
  • Rate-limit Incoming Port #22 Connections
  • Use Port Knocking
  • Use Log Analyzer
  • Patch OpenSSH and Operating Systems

[1] From: Mac OS X Maximum Security, 2003, John Ray and William C. Ray, p. 421

[2] From: Foundations of Mac OS X Leopard Security, 2008, Charles S. Edge, Jr., William Barker, p. 283