Ssh login with YubiKey + password on Debian

I bought a YubiKey a while ago. The first application for this was to enable two factor authentication for logging in remotely via ssh on my server. The procedure for this was as follows.

First install libpam-yubico with apt-get install libpam-yubico. Then edit /etc/pam.d/sshd and add the following ling before @include common-auth:

Make sure you change X and N to the values you get here.

Then edit /etc/pam.d/common-auth and modify the line by adding “try_first_pass” to the parameter list. For me, the line now looks like this:

You must also set up your YubiKey to be allowed to authenticate you. This is done by creating the file ~/.yubico/authorized_yubikeys on the server with content such as <user name>:<yubikey token ID>:<yubikey token ID>:...

The token ID is determinted by surfing to this page, selecting OTP as source format, putting the cursor in the string field and pressing the YubiKey. The token ID is the modhex encoded output string. It can look like this:

As a final step, make sure that password authentication is enabled in /etc/ssh/sshd_config:

Remember to restart sshd if you made any change. Now test it from another host:

See the YubiKey wiki for more information regarding this setup.

tellcore-py version 1.0.0 release

Yesterday I released version 1.0.0 of my Python wrapper for Telldus’ home automation library Telldus Core: tellcore-py

Telldus Core is Telldus’ open source library for using their TellStick products for controlling devices in the home. Tellcore-py aims to provide a “high-level” API on top of Telldus Core’s C API:

  • Has a more Pythonic interface with e.g. classes.
  • Automatically frees memory for returned strings.
  • Raises TelldusError exception instead of returning an error.
  • Transparently converts between Python and C strings, with full support for Python 3 strings.
  • Deals with callbacks from Telldus Core in a thread safe manner. Callbacks are dispatched on the main thread instead of the callback thread used by Telldus Core.
  • Extensive unit tests.
  • Supports both Python 2 and 3, and pypy.
  • Released as open source under GPLv3+.
  • Works on Linux, Mac OS X and Windows.
  • Documented

The source code is available on github, but the package can also be installed from Python Package Index: pip install tellcore-py

Even if this is version 1.0.0, the code has been under development for almost two years and is in use by e.g. tellprox.

badblocks again

I decided to run badblocks again. This time I measured how long it took:

417 / 24 = 17+ days…


After reading this post on Planet Debian and having seen this in my server logs a couple of times:

I determined that it was time to get some new disks for the server and ordered two Western Digital Caviar Red 2TB. After installing the first one in the server I started badblocks (8) as recommended in the post above. That was 18 days ago. The process finished yesterday…

We’ll see if I’ll do the same with the other disk. I’m currently waiting for the raid to be rebuilt before installing the second HDD.

Subversion repository on diet

A couple of months ago I wrote a python module to alter a subversion dump file in various ways.

It has now been used on a large dump file to remove the svn:mergeinfo property from all paths except from the root of all branches and tags. This made the repository shrink from 400 GiB to a more backup and mirror friendly 50 GiB. In the process some carriage returns were removed from svn:externals and svn:log to make the load work without –bypass-prop-validation.

The simple skeleton in combination with the README on GitHub should get you started if you are interested in using it.

Transparent HTTP proxy in python

I recently wanted to modify a web resource that a device on my local network loads when starting. To avoid having a static local modified copy of the resource I wrote a simple transparent HTTP proxy in python using the Twisted networking engine (which btw was a joy to use) which does the modification when the resource is loaded. The code is not modular (e.g. the resource modification is hard coded in the processResponse() function) and the logging is very verbose, but if anyone is interested the code is available on github: transparent-proxy.git.

The proxy is now running on my local server which sits behind the real gateway. Besides making the device use the server as gateway and enable NAT on the server this single iptables rule is all that is needed: