Difference between revisions of "SSH public keys"
Line 1: | Line 1: | ||
− | |||
− | |||
− | |||
[[Category:Ssh]] | [[Category:Ssh]] | ||
+ | [[Category:Engineering]] | ||
=== SSH Key Generation Overview === | === SSH Key Generation Overview === |
Revision as of 17:15, 23 May 2007
Contents
SSH Key Generation Overview
This shows how to use unencrypted public keys for logging in to SSH servers without a password. The basic steps are:
- Create an RSA key-pair with an empty password (no encryption).
- Copy the public key to the remote server.
- 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.
Usually it's bad to use unencrypted public keys for logging in to remote servers without a password. Only 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 learn about `ssh-agent`. That will give you most of the advantages of using unencrypted public keys with less of the risk.
The 'addremote' Script
The following script will store your public key on a remote server.
It uses your existing public key in ~/.ssh/id_rsa.pub
if it exists; otherwise, it automatically creates a new,
unencrypted key pair. That means you will be able to connect
to the remote server without a password.
If your private key is encrypted then you will need
to enter your key's password or add your key to ssh-agent.
Note that the password prompt comes from your server, not the remote server.
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 # This creates, copies, and installs a public key on a remote server. # Noah Spurrier usage="usage: addremote [-e] [-v] remote_hostname" while getopts ":evh" options; do case $options in e ) ENCRYPT=1;; v ) VERBOSE=1;; h ) echo $usage exit 1;; \? ) echo $usage exit 1;; * ) echo $usage exit 1;; esac done shift $(($OPTIND - 1)) REMOTE=$1 RSA_PRIV=~/.ssh/id_rsa if [ -z $REMOTE ]; then echo "Missing argument. Give username and remote host name in this format:" echo " $0 username@remote.example.com" echo $usage exit 1 fi if [ -r $RSA_PRIV ]; then echo "Using existing key: $RSA_PRIV" else if [ $ENCRYPT ]; then if [ $VERBOSE ]; then echo ssh-keygen -t rsa -f $RSA_PRIV fi ssh-keygen -t rsa -f $RSA_PRIV else echo "WARNING! Creating new, unprotected key: $RSA_PRIV" if [ $VERBOSE ]; then echo ssh-keygen -q -t rsa -N '' -f $RSA_PRIV fi ssh-keygen -q -t rsa -N '' -f $RSA_PRIV fi 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," $REMOTE if [ $VERBOSE ]; then echo scp $RSA_PRIV.pub $REMOTE:~/id_rsa.pub fi scp $RSA_PRIV.pub $REMOTE:~/id_rsa.pub echo "Adding public key to authorized_keys on remote host," $REMOTE if [ $VERBOSE ]; then echo ssh $REMOTE "mkdir -p ~/.ssh;chmod 700 ~/.ssh;touch ~/.ssh/authorized_keys;cat ~/id_rsa.pub >> ~/.ssh/authorized_keys" fi ssh $REMOTE "mkdir -p ~/.ssh;chmod 700 ~/.ssh;touch ~/.ssh/authorized_keys;cat ~/id_rsa.pub >> ~/.ssh/authorized_keys"
Creating a encrypted key
Having an key pair with an unencrypted private key is dangerous.
If anyone gets access to your private key this is as good as having your password.
Note that the addremote
script automatically creates an unencrypted key pair.
It will warn you before installing an unencrypted key in on a remote server.
It's usually best to create an encrypted key pair before using
the addremote
script.
ssh-keygen -q -t rsa -f ~/.ssh/id_rsa
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.
SSH Agent
When you ssh to a remote server where you have previously added your public key to authorized_keys then the remote server will ask your ssh client to confirm your public key. If your private key is not encrypted then your ssh client will confirm the keys without your help. If your private key is encrypted then your ssh client will ask you for your password to decrypt your private key.
You can have ssh cache your private key password so that you only need to enter it once. To do this, ssh uses ssh-agent to cache passwords. The ssh-agent sits in the background and caches the password to your private keys. On most desktop distros such as Ubuntu an ssh-agent is started when you login. The ssh-agent doesn't do anything until you add a private key to the cache. This will add your private key to the ssh-agent cache.
ssh-add
The agent will ask you for your password. Now the agent running in the background has your password and private key. When the ssh client later needs to confirm a public key it will first ask the ssh-agent if it has the key and password cached. If it does then the ssh client can confirm your keys without your help.
Debugging Your Agent
Most distros that feature a display manager such as xdm, gdm, or kdm will start an ssh-agent when you login. This is started as part of the xinit process. For example if you use KDE, then kdm is your display manager. Kdm will start X, which starts startkde, which starts ssh-agent.
root 4100 0.0 0.0 2688 640 ? Ss 18:18 0:00 /usr/bin/kdm root 4116 2.6 1.5 35236 23788 tty7 Ss+ 18:18 0:16 \_ /usr/bin/X -br -nolisten tcp :0 vt7 -auth /var/run/xauth/A:0-HgufQc root 4130 0.0 0.0 3664 1388 ? S 18:18 0:00 \_ -:0 noah 4896 0.0 0.0 1660 504 ? Ss 18:19 0:00 \_ /bin/sh /usr/bin/startkde noah 5113 0.0 0.0 4480 1004 ? Ss 18:19 0:00 \_ /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session /usr/bin/startkde noah 5168 0.0 0.0 1580 352 ? S 18:19 0:00 \_ kwrapper ksmserver
You can check if an agent is running by using this command:
$ ps auxww | grep agent noah 5113 0.0 0.0 4480 1004 ? Ss 18:19 0:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session /usr/bin/startkde
If you don't have an agent running you can put one in your .xsession. Or you can run it manually at any time from the command line:
$ exec ssh-agent bash
Older notes
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/
| |
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.
Newbie SSH Notes
Create a key pair
This creates a Public Key and a Private Key. The Public Key is what you can give to other people. Key is a bit of a misnomer. It's really more of a Public Lock. You keep the key. You can give the lock to anyone and they can lock stuff with it, but they can't unlock it. They can give you the locked data and only you can unlock it with your Private Key.
You can further secure your Private Key by encrypting it so that you need a pass work to use it. This way even if someone gets a copy of your Private Key that won't be able to use it.