Difference between revisions of "SSH public keys"

From Noah.org
Jump to navigationJump to search
Line 1: Line 1:
=== SSH Public Key Generation Overview ===
+
[[Category:Engineering]]
Generally it's bad to create public keys for logging in to remote servers without a password.
+
[[Category:Ssh]]
Use public keys in limited circumstances where you want a privileged account to have automatic
+
=== SSH Key Generation Overview ===
access to a remote server. Examples of this are backup accounts or Subversion repository accounts.
+
Generally it's bad to use unencrypted public keys for  
If you just want to make life easier for yourself because you don't like typing passwords when
+
logging in to remote servers without a password.
manually SSH'ing to a remote shell, then you should man ssh-agent. This uses public keys, but the
+
Use unencrypted keys in limited circumstances where  
keys themselves are protected by a password that you have to enter only once at the beginning of a session.
+
you want a privileged account to have automatic access to a remote server.  
 +
Examples of this are accounts for backup processes.
 +
On the other hand, if you are just looking to make life easier because  
 +
you don't like typing passwords, then you should use ssh-agent.
  
The basic steps:
+
The basic steps are
 +
# Create an RSA key-pair with an empty password.
 +
# Copy the public key to the remote server.
 +
# Add the public key to the authorized_keys file on the remote server.
 
<pre>
 
<pre>
 
ssh-keygen -q -t rsa -N '' -f ~/.ssh/id_rsa
 
ssh-keygen -q -t rsa -N '' -f ~/.ssh/id_rsa
Line 13: Line 19:
 
ssh user@remote.example.com "mkdir -p ~/.ssh;chmod 700 ~/.ssh;touch ~/.ssh/authorized_keys;cat /tmp/id_rsa.pub >> ~/.ssh/authorized_keys"
 
ssh user@remote.example.com "mkdir -p ~/.ssh;chmod 700 ~/.ssh;touch ~/.ssh/authorized_keys;cat /tmp/id_rsa.pub >> ~/.ssh/authorized_keys"
 
</pre>
 
</pre>
 +
If that seems like too much to remember then use the 'addremote' script below.
  
 
=== The 'addremote' Script ===
 
=== The 'addremote' Script ===
 
The following script will store your public key on a remote server.
 
The following script will store your public key on a remote server.
It uses your existing ~/.ssh/id_rsa.pub if available; otherwise, it
+
It uses your existing ~/.ssh/id_rsa.pub if it exists; otherwise, it
 
automatically creates a new unencrypted key pair <strong>without a password</strong>.
 
automatically creates a new unencrypted key pair <strong>without a password</strong>.
 
If you use an unencrypted key then you will be able to connect to the
 
If you use an unencrypted key then you will be able to connect to the
Line 24: Line 31:
  
 
Save this as "addremote" and chmod 755.  
 
Save this as "addremote" and chmod 755.  
You will have to enter your remote server password twice --  
+
You will have to enter your remote account password twice --  
once to copy the public key to the remote host
+
once to copy the public key to the remote host and
and once to activate the public key on the remote host.
+
once to add the public key to the list of authorized_keys the remote host.
  
 
<pre>
 
<pre>
Line 56: Line 63:
  
 
=== Permissions problems ===
 
=== Permissions problems ===
Ssh is very picky about permissions on ~/.ssh.
+
Ssh is very picky about permissions on the ~/.ssh directory and files.
Sometimes you may do something to mess this up.
+
Sometimes you may do something to mess up these permissions.
 
Run the following to fix most permissions problems.
 
Run the following to fix most permissions problems.
 
You may have to do this on both the remote host and local host.
 
You may have to do this on both the remote host and local host.
Line 65: Line 72:
 
   chmod 644 ~/.ssh/authorized_keys
 
   chmod 644 ~/.ssh/authorized_keys
 
   chmod 644 ~/.ssh/known_hosts
 
   chmod 644 ~/.ssh/known_hosts
Also no directory above ~/.ssh can have group or other write permissions.
+
Also no directory above ~/.ssh can have 'group' or 'other' write permissions.
  
 
=== Older notes ===
 
=== Older notes ===

Revision as of 14:00, 10 February 2007

SSH Key Generation Overview

Generally it's bad to use unencrypted public keys for logging in to remote servers without a password. Use unencrypted keys in limited circumstances where you want a privileged account to have automatic access to a remote server. Examples of this are accounts for backup processes. On the other hand, if you are just looking to make life easier because you don't like typing passwords, then you should use ssh-agent.

The basic steps are

  1. Create an RSA key-pair with an empty password.
  2. Copy the public key to the remote server.
  3. Add the public key to the authorized_keys file on the remote server.
ssh-keygen -q -t rsa -N '' -f ~/.ssh/id_rsa
scp ~/.ssh/id_rsa.pub user@remote.example.com:/tmp/id_rsa.pub
ssh user@remote.example.com "mkdir -p ~/.ssh;chmod 700 ~/.ssh;touch ~/.ssh/authorized_keys;cat /tmp/id_rsa.pub >> ~/.ssh/authorized_keys"

If that seems like too much to remember then use the 'addremote' script below.

The 'addremote' Script

The following script will store your public key on a remote server. It uses your existing ~/.ssh/id_rsa.pub if it exists; otherwise, it automatically creates a new unencrypted key pair without a password. If you use an unencrypted key then you will be able to connect to the remote server without a password and without ssh-agent. If your private key is encrypted then you will need to enter your key's password or add your key to ssh-agent.

Save this as "addremote" and chmod 755. You will have to enter your remote account password twice -- once to copy the public key to the remote host and once to add the public key to the list of authorized_keys the remote host.

#!/bin/sh
REMOTE=$1
RSA_PRIV=~/.ssh/id_rsa
if [ $# -ne 1 ]; then
    echo "Missing argument. Give username and remote host name in this format:"
    echo "    $0 username@remote.example.com"
    exit 1
fi
if [ -r $RSA_PRIV ]; then
    echo "Using existing key: $RSA_PRIV"
else
    echo "Creating new, unprotected key: $RSA_PRIV"
    ssh-keygen -q -t rsa -N '' -f $RSA_PRIV
fi
# Test if the private key is encrypted.
ssh-keygen -q -y -P '' -f $RSA_PRIV > /dev/null 2>&1
if [ $? -eq 0 ]; then
    echo "WARNING! Private key is not password protected."
    echo "This is not secure if you don't know what you are doing."
fi
echo "Copying public key to remote host."
scp $RSA_PRIV.pub $REMOTE:/tmp/id_rsa.pub
echo "Adding public key to authorized_keys on remote hosts."
ssh $REMOTE "mkdir -p ~/.ssh;chmod 700 ~/.ssh;touch ~/.ssh/authorized_keys;cat /tmp/id_rsa.pub >> ~/.ssh/authorized_keys"

Permissions problems

Ssh is very picky about permissions on the ~/.ssh directory and files. Sometimes you may do something to mess up these permissions. Run the following to fix most permissions problems. You may have to do this on both the remote host and local host.

 chmod 700 ~/.ssh
 chmod 600 ~/.ssh/id_rsa
 chmod 644 ~/.ssh/id_rsa.pub  
 chmod 644 ~/.ssh/authorized_keys
 chmod 644 ~/.ssh/known_hosts

Also no directory above ~/.ssh can have 'group' or 'other' write permissions.

Older notes

steps on local and remote servers
local server remote server
ssh-keygen -t rsa

Press enter when it asks you for a passphrase. This will set no passphrase. Or use

 ssh-keygen -t rsa -N 

to set an empty new password.

This generates the following files under ~/.ssh/

  • id_rsa -- Keep this secret!
  • id_rsa.pub -- Copy this to Remote
Copy id_rsa.pub to remote server:
scp ~/.ssh/id_rsa.pub user@remote.example.com:/tmp/id_rsa.pub

You will still need your password at this point.

Append /tmp/id_rsa.pub key to ~/.ssh/authorized_keys:
cat /tmp/id_rsa.pub >> ~/.ssh/authorized_keys

If you get an error saying "~/.ssh/authorized_keys: No such file or directory" it means that there is no .ssh directory for this user (this user has never used ssh before). Simply create an empty .ssh directory with 700 permissions:

mkdir ~/.ssh
chmod 700 ~/.ssh
You should now be able to ssh to the remote server without a password:
ssh user@remote.example.com

Things that often cause trouble

These are usually only problems when working with older SSH servers.

  • The SSH2 protocol specifies a format for storing public keys. Some SSH servers (such as ssh.com's) require a public key in this format in order to accept authentication with the corresponding private key. Others, such as OpenSSH, use a different format. I don't know what to do about this.
  • When cutting and pasting the public key BEWARE that it should be a single line. If you cut and paste from a terminal window then it is likely that you will get newline characters added where your terminal wrapped the line. If you use vi then the line may wrap and APPEAR to be multiple lines, but it is really one single line. When you paste it to a new window it may look the same, but the copy will likely contain newline characters. This will not work.
  • Make sure you are using the correct version. Earlier versions of OpenSSH used two files, authorized_keys and authorized_keys2. Secure SSH uses something else with keys in an entirely different format.