When a man is stimulated by his own thoughts, full of desire and dwelling on what is attractive, his craving increases even more. He is making the fetter even stronger. But he who takes pleasure in stilling his thoughts, practising the contemplation of what is repulsive, and remaining recollected, now he will make an end of craving, he will snap the bonds of Mara. His aim is accomplished, he is without fear, rid of craving and without stain. He has removed the arrows of changing existence. This is his last body. , ,


Ssh keys (key biased authentication) can be used as an alternate to using your user's login password (password authentication) to access a ssh server. Keys can be used with or without a password (not to be confused with the login password).

This document is intended as an introduction to using ssh keys to log into a ssh server. I will review the basics of generating and implementing ssh keys and it is assumed you already have a ssh server installed and configured to accept remote connections.

PAM links (note PAM modules vary slightly across Linux distributions):

PLinux PAM configuration that allows or deny login via the sshd server
Pulling The Covers Off Linux PAM
The Linux-PAM System Administrators' Guide

Generate keys

Keys come in pairs, a private key and a public key (see below). The public key is placed on the server and the private key is used by the client to log onto the server.

In general, I advise a unique key for each user on each server, however, you can use a pair of keys for as many users/clients/servers as you wish.

Using the command line

Keys can be generated on the command line using "ssh-keygen". The general syntax to generate a key pair is :


Enter your desired password when prompted (you will not see anything on the screen as you type). To generate a key with no password, simply hit the enter key.

This command will generate two files, id_rsa and id_rsa.pub

You may specify a different name for your key pair with the -f option. For example to make a key named "foo", use -f foo :

ssh-keygen -f foo

This will generate two files:

You may use most any name you desire for you key.

Using graphical tools (seahorse)

Seahorse is a graphical tool to manage ssh keys. It has a number of features including key generation and managing keys. Seahorse will generate ssh keys and transfer your key to the ssh server (as long as passwords authentication is allowed).

There is a nice write up on how to use seahorse here (Debian Admin): SSH Key Authentication Using seahorse (GUI)

Changing the key password

You can change your key's password either on the command line ( with ssh-keygen -p ) or from seahorse (graphical).

From the command line, use ssh-keygen with the -p option:

ssh-keygen -p -f ~/.ssh/id_rsa

Enter the old PW, then the new.

If you forgot the old password, you are out of luck and will need to generate a new key.

Transfer the key to the ssh server

You may do this via the easy way or the hard way.

Public keys are stored by default in ~/.ssh , one key per line (a user may have multiple keys). You can change the location by editing /etc/ssh/sshd_config (see man sshd_config ).

Easy way - use ssh-cop-id

ssh-copy-id is a command that automates transfer of your public key to the server. To perform the transfer you will need to log in, so do not disable password authentication until after you confirm the key is working.

ssh-copy-id -i key_name user@server

ssh-copy-id -i id_rsa bodhi@ssh.server.com

ssh-copy-id -i foo bodhi@ssh.server.com

Hard (Manual) way

You can manually transfer the key as outlined below.

First, using any method, transfer the .pub key to the server. You can do this using a network protocol (scp) or sneakerware (flash drive).

You then copy or add the .pub key to ~/.ssh/authorized keys.

Run these commands on the server (substitute the name of your key as needed).

cat id_rsa.pub >> ~/.ssh/authorized_keys

cat foo.pub >> ~/.ssh/autorized_keys

Using the key to login to a ssh server

By default, the private key should be stored in ~/.ssh , although you can keep it anywhere you wish.

Use the "-i" option with ssh to specify the private key you wish to use to log into the server.

ssh -i ~/.ssh/id_rsa bodhi@ssh.server.com

ssh -i ~/.ssh/foo bodhi@ssh.server.com

If you are using PuTTY, you specify the private, .ppk key (Under SSH -> Auth in the menu on the left).

You may use one key per client or you may use the same key on many clients. You may carry the private key with you on a flash drive.

Note on permissions :

Your ssh keys and the authorized_keys file must have restrictive permissions.

ssh keys can not be "world readable" Permissions must be 400 or 600 :

Otherwise you will see this error message :

Permissions 0440 for './id_rsa' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.

To fix this message, use chmod:

chmod 600 id_rsa

authorized_keys can be world readable, but only writable by the owner.

You will not get an error message here, the key simply will not work.

To fix this, use chomd.

chmod 600 authorized_keys

You can use permissions of 400, 440, 444, 600, 640, or 644 .

For additional information on Linux permissions see : Linux permissions


PuTTY is a ssh client and runs on both Windows and Linux. You can not use openssh keys directly with PuTTY (PuTTY uses it's own key, a .ppk or PuTTY Private Key). You can import your openssh key with PuTTYgen and save it as a PuTTY ppk key.

For a detailed walk through, see : How to import ssh keys to putty using PuTTYgen

Note : Be sure to save the key with the ssh2 protocol.

PuTTY will save the private keys ending in ".ppk" (Putty Private Key). If needed, save the public key as a .pub (same as openssh key pairs). If needed, you can import the PuTTY .pub keys to a server, similar to above (copy the PuTTY .pub key to ~/.ssh/authorized_keys).

id_rsa.ppk or foo.ppk

You may import public PuTTY keys to a ssh server as above.

Disable password authentication

Before disabling password authentication, first make sure you can log in to your server with a key

If you disable password authentication you will not be able to log into the server (remotely) without a working key. Do not disable password authentication without either a working key or physical access to the server.

Using any editor, edit /etc/ssh/sshd_config

nano /etc/ssh/sshd_config


PasswordAuthentication yes


PasswordAuthentication no

Save your changes and restart (or reload) the ssh server.

sudo service ssh reload

If you attempt to log in without a key you will now get an error message :

Permission denied (publickey).

Using keys without entering a password

Rather then generating a key without a password, you can use ssh agent (command line tool) to load your ssh keys into memory. Once a key is loaded into memory, you can ssh into the server without manually entering the password.

In theory (and on some web pages) seahorse *should* automatically load your ssh keys when you log in. In practice, in my experience, the keys often fail to load. In that event you would need to fall back to the command line (ssh-add).

To use ssh-agent, first load the key:

ssh-add -i ~/.ssh/id_rsa

Enter your password when prompted. You can the ssh into the server without entering a password.

ssh bodhi@ssh.server.com

Notice you do not need to specify the key and ssh connects without asking a password

ssh-add is capable of loading multiple keys and has a few additional options including -x to lock and -X to unlock the agent.

SSH Agent without X

ssh-agent can be run without X, from a console, by starting a new shell. You may want to run a new session in "screen".

ssh-agent bash
ssh-agent zsh #for those who prefer zsh to bash

This starts a new {bash,zsh} shell and you may now add keys with ssh-add as above. This option works well with screen.

See the man page for additional information : ssh-add(1) - Linux man page

Forced commands

You can limit what a user can do using a key by using a technique called forced commands. I will leave the details of forced commands for another day, but these links should get you started:

Openssh going flexible with forced commands
Restricting SSH commands
O'Reilly Online Guide - SSH: Per-Account Server Configuration