SSH authentication with your PGP key

A few weeks ago I learned that a few of my colleagues were using PGP. I myself started using PGP around 2003, using the GnuPG implementation. However, since I didn't know many people who used it my usage slowly faded after a few years. In 2009 I shortly picked it up again by creating a new key to phase out SHA-1, but that was also of short duration. Thanks to my colleagues, I'm now starting to use GnuPG again. My key is still the same as created in 2009: 610DB834.

I noticed that both my PGP-key and my SSH-keys use the RSA-algorithm, so I started wondering whether it was possible to use my PGP-key to authenticate myself to SSH-servers. After some Googling it seemed possible, but not very straightforward. In the end I managed to get it working, thanks to the very friendly support of Werner Koch (the main developer of GnuPG). Since it is not very straightforward I will document my findings here for future reference.

Adding an authentication key

First add an authentication subkey to your PGP-key, as it is apparently a best practice to use subkeys for each type of usage. To do so you need to start gpg with the --expert flag like this:

# where 610DB834 is the id of my key
gpg --expert --edit-key 610DB834

When you are in gpg type addkey and type '8' to choose (8) RSA (set your own capabilities). This option let's you manually configure the new key. Then type (each time followed by enter): S, E, A, Q, so that it says 'Current allowed actions: Authenticate'. Then choose a keysize (I use 4096) and an expiration date (5 years from now for example) and wait for the key to be created. Finally save to save your key. Your authentication-subkey is now ready.

How I upgraded to Drupal7. Part2

This is the second part of a series on how I upgraded my website from Drupal 6 to Drupal 7. The sources for my website are freely available on my github account.

Automating as much as possible

When I started working on the new version of the site, I did not only want to be able to install the site from scratch. I also wanted the one-time upgrade from Drupal 6 to Drupal 7 to be as smooth as possible. However, the life of a website doesn't stop once the initial deploy (or 're-deploy' in this case), is done. In fact, it only begins at that point. You will need to keep the site updated with new functionality and, more importantly, with security updates. Sadly, this deployment and updating is often an afterthought, or not done at all. Let's face it, deployment and updates are boring and a risky task. So I wanted a setup where I could as easily as possible deploy and update my site, without having to think much about it.

I have split up everything which needs to be done into a few simple steps and written scripts for it.

How I upgraded to Drupal7. Part1

This is the first part of a series I plan to write on how I upgraded this site to Drupal 7. I have made all the sources available on my github account, as it can serve as an example on how to do Drupal development without database dumps. These are the parts I plan to write:

You can find the sources here:


Nearly 1,5 years ago I decided that I wanted to migrate my Wordpress blog and two other custom sites into a single Drupal based website. At that time Drupal 7 was not yet final (or just a few days, can't remember exactly) and was not yet really in a usable state for a regular site without too much difficulties. So I went with Drupal 6 and I decided to use the 'classic' method of Drupal development: database dumps. I figured that, since it was just for my personal site, it didn't really matter. For deployment I used rsync.

Drupal Development: some tools and utilities

I finally took the time to make my 'drupaldev'-repository available.

First a short introduction: It is my strong opinion that Drupal modules which are only used during development, such as devel, diff, etc, should never be deployed to production. They shouldn't even be in the repository. Instead, I keep a personal collection of development-modules in a separate repo. Thanks to the fact that Drupal recursively searches for modules inside the modules folder, I can simply create a symlink to my collection of development modules. This allows me to use my preferred modules, even though they are not in the repository for the project.

For Drupal7, I usually just create a symlink, named devmodules7, in sites/all/modules. Like this:

# from the drupal root of the project
ln -s ~/drupaldev/devmodules7 sites/all/modules/

The repository itself contains a collection of modules, for both Drupal 6 and Drupal 7, and some utility-scripts. After experimenting with copies of the modules and git submodules, I finally settled on drush make to manage the modules. Instead of copying all the modules in my repo, I only keep a make-file for each Drupal version (currently 6 & 7). This makes it really easy to update all the modules, as I can simply run the makefile again. To make this even easier I have added a build script which will run all the drush make-files with the correct arguments: