SSH key and passwordless login basics for developers

SSH keys are useful to login over ssh (secure shell) without typing a password. They are also used by Github and other version control systems for passwordless authentication. Here is some basic information from the software developer point of view how to use SSH keys for maximum comfort and security.

These instructions apply for OSX and Linux (tested on Ubuntu).

SSH keys are not used only by shell sessions, but also by remote file copy (rsync, scp) version control system authentication (Git, Subversion).

Table Of Content

1. Creating your first key

2. Storing the server (UNIX) passwords

3. Private and public key file

4. Managing and using keys with passphrases

5. Desktop and login integration

6. SSH agenting and passwordless git and svn

7. Online compression of the SSH traffic

8. Configuration files

9. Tunneling

10. Freeing yourself typing password for sudo

1. Creating your first key

SSH keys are created using ssh-keygen command.

You should (really must!) add a passphrase on your key when asked. You don’t need to be typing this, but it prevents someone using your keys from a cold storage like stolen hard-disk. See more information below how SSH keys are integrated to your desktop computer login for avoiding passphrase typing.

2. Storing the server (UNIX) passwords

On the first login to a new server change your UNIX / SSH password to something random usingpasswd command. You are going to need this password for sudoing, but not for login. You can use software likeKeePassX (OSX, Linux, Windows, Android, others) to generate and manage passwords for you in an encrypted file and then sync the file to Dropbox for back-up.

3. Private and public key file

SSH keys consist of two parts. You have SSH private keys only on your personal computer. You place the public key file on a remote server, in a home directory in plain-text file~/.ssh/authorized_keys. In this file, one line represents one allowed public key for this user to login.

You can add the keys to this file by hand editing the file or using ssh-copy-id command (Ubuntu has it by default,download for OSX).

Example of login on the server with password for a test, placing a key (github-pkunk is the private key file name) on the server (you need to create it first using ssh-keygen) and then doing a passwordless login:

4. Managing and using keys with passphrases

You can have multiple keys. For example I have one for Github and one for corporate servers.

After each local computer boot you add the private keys to your running SSH agent (a local daemon application) using commandssh-add .ssh/my-private-key-name This will ask you to type the passphrase of the key.

After this you can login to any server where you have placed the corresponding public key without a password.

You can add / change passphrases to they private keys like this:

                                                                                                                                                                                                                                                    [moo@Kohr-Ah][23:23][~/.ssh]% ssh-keygen -p -f github-pkunkKey has comment 'github-pkunk'Enter new passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved with the new passphrase.

(More info)

5. Desktop and login integration

On OSX, adding keys to the SSH agent can done automatically by OSX Keychain on login. OSX Keychain stores the passphrase of the key on an encrypted storage unlocked by your login on the computer. The default key ~/.ssh/id_rsa is added automatically by OS, but you can add more keys to Keychain like this:

[~/.ssh]% ssh-add -K github-pkunkEnter passphrase for github-pkunk: Passphrase stored in keychain: github-pkunkIdentity added: github-pkunk (github-pkunk)

The latest Ubuntu / Gnome keyring seems to be able to do this also, but I am not sure about the details whether the process is the same.

(More info)

6. SSH agenting and passwordless git and svn

Never copy your private key anywhere else besides 1) your own computer 2) back-up. You should never place your private key on a server controlled by a third party. If you need to access SSH keys on a remote server, for example when you need to do a git pull from Github, use SSH agent forwarding option.

SSH agent forwarding allows the remote server shell session to use keys from your local computer. It is enabled withssh -A command line switch or in an option in the configuration file (see below). When enabled, all keys registered withssh-add will be available on the remote server.

Subversion supports SSH. This means that, when enabled, you can do svn up on a remote server without need to give or store your SVN password on the server. The svn+ssh protocol support for Subversion must be enabled and it may not provide per-user repository access control, as oppose tohttps protocol with Apache.

7. Online compression of the SSH traffic

Enable compression when working with servers far-away with low bandwidth. See below how to enable this in the ~/.ssh/config file.

This will somewhat increase the speed of long command output like ls.

8. Configuration files

Store the servers you access often in .ssh/config file. You can store per-server options like enable agent forwarding, server alias (shorter to type) and  default username. Here is an example snippet from my config:

Host xapsi Hostname lakka.xapsi.fiUser miohtama # This is my username on the serverLocalForward 8889 localhost:8889 # Build tunner for Quassel IRC coreCompression yes # Enable compressionCompressionLevel 9IdentityFile=/Users/moo/.ssh/foobar # Always use this key

The configuration file also enables the tab competion on some shells (zsh examples). With the above snippet in the config I could do:

ssh kap[TAB][ENTER]

Login with 6 letters – no passwords or usernames asked!

9. Tunneling

SSH key can forward TCP/IP ports between the server and your local computer. This is useful e.g. testing firewalled servers from a local computer or give a public IP / port for your local development server.

More info about SSH tunneling.

10. Freeing yourself typing password for sudo

For the state of the art UNIX system the direct root SSH account is disabled for the security reasons. Instead you ssh in as a normal user and then elevate your privileges usingsudo command.

Normally sudo is configured to ask password for every time sans sudo grace period. However if you primarily use SSH keys as your security measure it is recommended that

• You randomize and store the real UNIX passwords in an encrypted safe as described above
• You put sudo users to a specific UNIX system group (on Ubuntu this is group admin, but also wheel is used on some systems)
• Give passwordless sudo access for this group and this group only

Example how to add an account to a specific group on Ubuntu Linux:

usermod -a -G admin moo

Then you can whitelist this group in /etc/sudoers file:

%admin ALL=(ALL) NOPASSWD: ALL

The recommended safe way to edit /etc/sudoers file isvisudo command. Example:

 export EDITOR=nano && sudo visudo

Please note that you MUST use only passphrase protected private keys or otherwise anyone getting access to a private key file can get root on your server.

Please note that you should give passwordless sudo only on specific users on your server. Otherwise in the case of a compromised web server (PHP anyone?) the attacker could get root access throughwww-data or other UNIX system account.

Please share your own tips in the blog comments.