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).

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 using passwd command. You are going to need this password for sudoing, but not for login. You can use software like KeePassX (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 command ssh-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-pkunk
Key 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-pkunk
Enter passphrase for github-pkunk: 
Passphrase stored in keychain: github-pkunk
Identity 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 with ssh -A command line switch or in an option in the configuration file (see below). When enabled, all keys registered with ssh-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 to https 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.fi
User miohtama # This is my username on the server
LocalForward 8889 localhost:8889 # Build tunner for Quassel IRC core
Compression yes # Enable compression
CompressionLevel 9
IdentityFile=/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 using sudo 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 is visudo 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 through www-data or other UNIX system account.

Please share your own tips in the blog comments.

 

Buy open source friendly bitcoins  Subscribe to this blog in a reader Follow me on Twitter Follow me on Facebook Follow me Google+

16 thoughts on “SSH key and passwordless login basics for developers

  1. Thanks for this blog post.

    I did not yet know about the ‘ssh -A’ option. Brilliant! I could have really used that earlier this week…

  2. Its also worth noting that running with ssh-agent ( or any such credential cache proxy ) is generally considered bad, since a compromise on your machine, and this could even be via the web-browser, will result in compromised access to the endpoints ( which are very easy to find, since they are logged in your known_hosts ).

    Also worth noting that cached credential layers invalidate your organisations PCI certifications if the remote endpoint is inside the PCI certified zone. But then, I am sure everyone uses jumphosts and does connection auditing with the right two factor auth and developers are never allowed access to production machines from untrusted sources ……

  3. I surely hope the people dealing with PCI certified environments don’t need to come to my blog to read SSH basics ;)

  4. Great post, very useful for SSH newbies. One are you could improve the post is explaining when/why I should use multiple SSH keypair or a single keypair.

  5. Pingback: Bookmarks for 11 October 2012 through 25 October 2012 « Pilgrim Steward

  6. Reasons for using multiple keys is usually the situations where you work in multiple organizations having different roles. For example, I could have a key for my private use, then for PyCon Finland volunteer work and then various keys of the client companies I am working with. It is not entirely clear in the post when you have such use cases, but at least having the separation between personal / corporate key makes sense.

  7. From the ssh man page:

    Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent’s UNIX-domain socket) can access the local agent through the forwarded connection. An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent.

  8. Question about ssh access to a computer from from a public wifi network. While paswordless login (with ssh keys) works on a laptop on a home/soho network, when trying to connect from a public wifi network (in a coffee shop), I get a “permission denied (public key) error”. Don’t really understand enough about ssh to figure out the right configuration but it seems that the last part of the rsa key stored in the authorized_keys file has user@machine.local whereas while connecting from the public network network name changes

  9. Network name change does not affect the public key login. The network name is only used inside they key file as a description to tell which computer the key was created on.

    Use ssh -v to enable verbose ssh output to debug problems.

  10. When an organisation or company added us in github for pull and push of code. Is our SSH key has to provide to them or not..?
    Can you suggest me regarding this..?

    Thanks,
    Somasekhar

  11. Unfortunately I am not support person of the company which name you do not mention or not support person of Github so I cannot have no idea what is going on. Please contact the company in the question.

  12. Pingback: Linux server ghetto duplication

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>