So, what is this all about? Every now and then I want to try if I can solve some programming problem and make a tiny new project for that. For convenience I publish them on GitHub so I can clone them and play with them from multiple computers. Maybe someone else finds it and it helps someone, who knows.

I could name those tiny (not so) throw away projects like “testthis” or “evaluatethat” or come up with some more or less matching name, but GitHub has a nice feature when creating new repositories, GitHub makes a naming suggestion and I just pick that. See:

Screenshot GitHub new repository creation

Create a new repository on GitHub

Over time the number of those projects grew and to not lose track of them, here is a list:

Bridges with meaningful error messages

Just wanted to create a network bridge interface on an embedded Linux system. First try was with the well known brctl and I got this:

$ brctl addbr br0
add bridge failed: Package not installed

Searching the web for this, led me to an old blog post which comes to this conclusion:

So that’s the most silly way to say: you forgot to compile in bridge support into your kernel.

ip from busybox is a little more helpful on that:

$ /sbin/ip link add name br0 type bridge
ip: RTNETLINK answers: Operation not supported

And yes, the “real” ip from iproute2 is also as helpful as that:

$ /usr/sbin/ip link add name br0 type bridge
RTNETLINK answers: Operation not supported

And yes, somehow they are all right, it is actually my fault:

# CONFIG_BRIDGE is not set

I’m going to change my kernel config now …

HowTo: Debug core dumps with ptxdist 2017.07.0

Debugging for embedded projects is a little harder than for your own computer. In many cases you can not run gdb on the target, and even if you can use gdbserver1 this does not cover all use cases. For post mortem analysis (e.g. after a segmentation fault of your program) you want to examine so called core dumps. Given you successfully found out how to let your target create those2, copied it to your workstation and unpacked it, you still need to know how to analyze it.

With the release of ptxdist 2017.07.0 the handling of debug information changed. Quoting from the release announcement:

The debug symbol handling was reworked. The debug files are now named based
on build-ids and (optional) debug IPKGs can be created. They are not
installed by default but can be installed manually as needed. This is
useful to gdb on the target or with valgrind and perf.

In my BSP those debug info is put to /usr/lib/debug in the root folder from which the target files are copied. This looks like this now:

% tree -a ./platform-foo/root/usr/lib/debug | head
└── .build-id
    ├── 00
    │   └── ba20cb0e075c4dc0a792a9062b0864ced517b1.debug
    ├── 03
    │   └── 3b4fc351317376388fadb19fc63b4c8ab6c0d9.debug
    ├── 04
    │   ├── 01fe993aa2bed2155514c676d7001625732396.debug
    │   ├── 7bdbc5fd44a4444de24762c76a3313d1fda2c0.debug
    │   └── d0ecb6611e590a036cbdd5909cc5bfc9158af8.debug

You can imagine it is not possible anymore to load this manually, the debugger will have to find out by itself. Getting this to work caused me some headaches, but this it how I got it work: Create a file ‘gdb-config’ with the following content:3

set debug-file-directory /home/adahl/Work/bsp/foo/platform-foo/root/usr/lib/debug
set sysroot /home/adahl/Work/bsp/foo/platform-foo/root

Note: the order of the commands is important, it does not work the other way round!

Then load your core dump:

% ./platform-foo/selected_toolchain/arm-v5te-linux-gnueabi-gdb -x ./tmp/gdb-config -e ./platform-foo/root/usr/local/bin/yourtool -c ./tmp/cores/2017-08-16/core 

So you run the gdb from your toolchain, load the previously crafted file with gdb commands with -x, give the path to your executable with -e and finally the core dump file with -c and that’s it. You may now have a look at a backtrace and find out what caused the segfault …

Update: I was pointed to an easier possibility to invoke the right gdb with the necessary options in #ptxdist IRC channel (on freenode). The previous call would be like this:

% ptxdist gdb -e ./platform-foo/root/usr/local/bin/yourtool -c ./tmp/cores/2017-08-16/core 

No need to pick the correct gdb and find and configure the right directories, just add the path to your tool and your core file, ptxdist handles everything else. I bet this would also work with older ptxdist versions, where the debug symbols where placed somewhere else, but didn’t try it. This however was also just added with ptxdist 2017.07.0:

There is also a new ptxdist command ‘gdb’ for remote debugging that sets up
the sysroot correctly and a wrapper script that can be used by graphical
development environments.

  1. we already had this topic here: KDevelop: Debuggen von Programmen, die root-Rechte benötigen (German) []
  2. this would be content for another post []
  3. of course you adapt the paths to the ones you use on your machine []

Do not change already released files!

tl;dr: Please upstream developers: Do not ever change what you already published, but make an additional version with your fix. This causes less trouble for people building your stuff.

As some of you might have noticed: I’m a little into embedded Linux software and contribute to some of the build systems around, mainly to buildroot (for fli4l) and to ptxdist (at work). This is a very special kind of fun meaning constantly trying to fix things gone wrong. Today is a day where the temperatures outside I’m stuck, because someone else fucked up his stuff.

Last week I built myself an image for testing iperf on a BeagleBone Black with the current buildroot master. This got me a tarball iperf-2.0.9.tar.gz from some mirror server. This worked.

Today I upgraded a ptxdist BSP from some older state, I think 2016.12.0, to the recent ptxdist 2017.06.0 which included an upgrade of the package iperf from 2.0.5 to 2.0.9. This got me a complaint about an invalid checksum. Those embedded build systems contain checksums for tarballs, buildroot uses mostly sha256, while ptxdist still uses md5. This is mostly to ensure transport integrity, but it also triggers when the upstream tarball changes. Which it should not.

So now the checksums in buildroot master from today are still from buildroot changeset 2016.05-1497-g11cc12e from 2016-07-29:

# From
sha1    9e215f6af8edd97f947f2b0207ff5487845d83d4        iperf-2.0.9.tar.gz
# Locally computed:
sha256  a5350777b191e910334d3a107b5e5219b72ffa393da4186da1e0a4552aeeded6  iperf-2.0.9.tar.gz

Those are the very same to the file I have locally. Note: both ptxdist and buildroot download archives to the same shared folder here. The md5sum of this file is 1bb3a1d98b1973aee6e8f171933c0f61 and ptxdist aborts with a warning this sum would not match. Well in ptxdist the iperf package was changed on 2016-12-19 last time, also upgrading from iperf 2.0.5 and here the changeset is ptxdist-2016.12.0-10-gd661f64 and the md5sum expected: 351b018b71176b8cb25f20eef6a9e37c. This is the same you can see today on, but why is it different from the one above?

To find out I downloaded the file currently available on, which was last changed 2016-09-08, after buildroot included the package update. The great tool diffoscope showed me, a lot of the content between those two archives was changed. But why?

Seems I was not the first one noticing: #20 Release file: iperf-2.0.9.tar.gz changed!!! And the maintainer set it to WONTFIX.

Now this is the point where I’m not sure whether to just get pissed, deeply sighing, or trying to fix the mess for those build systems. The clean way would be upstream releasing some new tarball, either the one or the other or even make a new release, named 2.0.9a or whatever.

What are possible solutions?

  • Wait for upstream to make a clean, new release. (And hope this doesn’t get changed in the future.)
  • Upgrade those hashes in buildroot. This obviously breaks old versions of buildroot.

According to the buildroot IRC channel, they want their package to be updated, even if older releases will break. And they said they have a fallback and use their own mirror, so that’s where my first package may have come from.

Update: buildroot accepted my patch updating those hashes quickly.

dropwatch moved

While debugging some network packet loss I stumbled over a blog post from 2013: Dropwatch to see where the packets are dropped in kernel stack. And another one: Using netstat and dropwatch to observe packet loss on Linux servers. I wanted to try it, but unfortunately where it was hosted previously is history since March 1st, 2017.

My favorite distributions and build systems didn’t have dropwatch as package or still used the old addresses so I looked for some clones at GitHub, got the E-Mail address of what appeared to be the maintainer and got in contact. I got a friendly reply and – good news everyone – the project is still maintained and moved to:

Hope this helps someone, maybe when this page hits the search engines. ;-)

Let a LED blink in different frequencies on Linux

There’s an embedded Linux board on my desk, where a LED is connected to some GPIO pin. Everything is set up properly through device tree and with a recent kernel 4.9.13 the usual LED trigger mechanisms work fine, so no problem using heartbeat or just switching the LED on and off.

Now I wanted to have the LED blink with certain patterns and it turns out, this is quite easy given you know how. You have to set LEDS_TRIGGER_TIMER in your kernel config first. Now go to the sysfs folder of your LED, here it is:

cd /sys/class/leds/status

Have a look at the available triggers:

$ cat trigger 
[none] timer oneshot mtd nand-disk heartbeat gpio default-on panic

Switch to the timer trigger:

$ echo timer > trigger

Now two new files appear, delay_on and delay_off. Per default both contain the value 500 which lets the LED blink with 1 Hz. Without further looking into the trigger code or searching for documentation I assume those values are the on and off times in milliseconds. So have the LED blink with a certain frequency the following formular could be used:

f_LED = 1000 / ( delay_on + delay_off )

So to set my LEDs to blink at 2 Hz frequency, I set it up like this:

$ echo 250 > delay_on
$ echo 250 > delay_off

Happy blinking!

Run Unit Tests from Shell

For a certain reason I have a bunch of binaries which are in fact unit tests. Each of them returns 0 as exit code in case of success and some other value if it fails. I wanted a lightweight solution to run all these tests and printing out the result. What I came up with is a ~50 line shell script which reads the list of tests from a simple text file. In this text file all you have to put in is one command per line, which gets executed by the script then. First see a sample list of tests:

# line will be ignored
uname -a

The actual script running the tests, I named it for obvious reasons, looks like this:

# ----------------------------------------------------------------------
# Run tests from a simple text file with a command on each line.           
# Copyright 2017 Alexander Dahl
# ----------------------------------------------------------------------
. /usr/local/share/colsh/                             
. /usr/local/share/colsh/                                   
if [ -z "${1}" ]                                                           
    echo "Usage: ${0} LIST"                                                
    exit 1                                                                 
if [ ! -f "${1}" ]                                                         
    cecho --err "Test list file '${1}' does not exist!"                    
    exit 1                                                                 
while read line                                                            
    # skip lines starting with '#'                                         
    if [ -z "${line%%#*}" ]                                                
    eval ${line} >/dev/null 2>&1                                           
    if [ $? -eq 0 ]                                                        
        TESTS_GOOD=$(expr ${TESTS_GOOD} + 1)                               
        echo -e "[${COL_INFO}✔${COL_RST}] '${line}'"                       
        TESTS_BAD=$(expr ${TESTS_BAD} + 1)                                 
        echo -e "[${COL_ERR}✘${COL_RST}] '${line}'"                        
done < "${1}"                                                              
TESTS_SUM=$(expr ${TESTS_GOOD} + ${TESTS_BAD})                             
if [ ${TESTS_BAD} -gt 0 ]                                                  
    cecho --warn "${TESTS_BAD} of ${TESTS_SUM} tests failed!"              
    exit 1                                                                 
    cecho --info "${TESTS_GOOD} of ${TESTS_SUM} tests successful."         

Note the inclusion of two files from my own project colsh at the top for nice colors. The sample output below is not colored, so you have to try the script by yourself to see it. The script runs fine with bash and also with busybox, which was my intended target. Now see some sample output:

[✔] 'uname -a'
[✔] '/bin/true'

2 of 2 tests successful.

See the script showing you if the test was successful and the original command. In case of failing tests you can just copy the command from the failed line, paste it in another shell and execute it to see its output or otherwise debug it. Note my script suppresses the output of the called commands to not clutter its own output. Another output, this time with a failed test:

[✔] 'uname -a'
[✘] '/bin/false'

1 of 2 tests failed!

You probably noticed the marks in the brackets are unicode, your environment should be set to some UTF-8 locale. ;-)

Automatisches rsync über SSH absichern

Im ersten Teil dieser Serie ging es im weitesten Sinne um Let’s Encrypt. Mein persönliches Setup hier macht es aber nötig, die fertigen Zertifikate nochmal sicher auf eine andere virtuelle Maschine zu kopieren. Wie das grundsätzlich mit OpenSSH funktioniert, konnte man im zweiten Teil lesen. Jetzt kommt die Kür, die Absicherung dieses Kopierens inklusive sicherem rsync-Zugriff. Lässt sich sicherlich auch für andere Zwecke wie Backup-Server anpassen. ;-)

Wrapper-Skript auf dem Zielserver

Was wir jetzt noch wollen: in unserem Wrapper-Skript, das zunächst mal nur den aufgerufenen Befehl in ein Log-File geschrieben hatte, soll die Umgebungsvariable SSH_ORIGINAL_COMMAND analysiert und gegen erlaubte Befehle abgeglichen werden. Nur im Wrapper-Skript erlaubte Befehle werden ausgeführt. Direkt über SSH abgesetzte Befehle sind hier leicht abzufangen, weil sie genauso ankommen, wie auf dem Quellsystem eingegeben. Interessant wird es mit rsync. Dem sagen wir ja auf dem Quellsystem was ganz anderes, als auf dem Zielsystem im Log erscheint, zum Vergleich nochmal ein (expandierter) rsync-Aufruf:

rsync -e 'ssh -i /home/alex/.ssh/id_rsa_acme' /home/alex/

Um hier im Wrapper-Skript den Befehl, den rsync über SSH tatsächlich absetzt, korrekt matchen zu können, braucht’s entweder hellseherische Fähigkeiten, sehr viel tieferes Verständnis von rsync oder ein trial und error mit einem Log-Skript wie in Teil zwei der Serie. Man kann aber noch einen Schritt weitergehen und daher schweifen wir nochmal kurz ab …

rrsync zur Absicherung von unbeaufsichtigten rsync-Aufrufen

Dass das mit rsync kompliziert ist, haben auch andere Leute bemerkt, auch bei Samba selbst, unter deren Dach rsync entwickelt wird. Und so gibt es rrsync. Bei Debian ist es im Paket rsync die Datei /usr/share/doc/rsync/scripts/rrsync.gz, die man sich in temporäres Verzeichnis kopiert, dekomprimiert, mit chmod +x rrsync behandelt und dann in einen Ordner bin kopiert, ich hab’s in /home/alex/bin/ abgelegt. Es handelt sich um ein etwa 200 Zeilen langes Perl-Skript, das rsync nochmal auf die Finger schaut.

Die Dokumentation von rrsync ist leider sehr dünn. Wenn man das Skript ohne Parameter aufruft, erhält man:

Use 'command="./bin/rrsync [-ro] SUBDIR"'
        in front of lines in /home/alex/.ssh/authorized_keys

Das erklärt im Grunde schon den Hauptzweck: man kann rsync-Zugriffe auf bestimmte Verzeichnisse beschränken. Außerdem werden nur gültige rsync-Aufrufe zugelassen und man kann über nicht dokumentierte Optionen die zugelassenen rsync-Optionen noch weiter einschränken. Wer davon Gebrauch machen will, sollte sich das Skript rrsync selbst nochmal anschauen. Darüber hinaus erleichtert rrsync die Verwendung von rsync in einem Wrapper-Skript, werden wir dann gleich noch sehen.

Erstmal nur rrsync ohne Wrapper-Skript. Dazu ändern wir auf dem Zielserver in der ~/.ssh/authorized_keys die Zeile mit unserem public-Key, so dass vorn als command rrsync angegeben wird:

from="",command="/home/alex/bin/rrsync .cert",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC9VKFUIcc+vfL3a9oFNeuITghF7+QYtTvlpsX7CHG/UmEIIIpz31n6TEoSCL0a4sA6Xx2Z+peGbYD1RRzH/6Shis/4L+R2HPSA+1TqLKT4fdyF9Xkbj9E/bbmrXx5fH8DZnYThIJ15mVHUO7eALU2ELxa+mwehxPbV070qFo1Y1lGa93dhJSdXMerFQE7YPf8UXlb1ULJA+AneQNMymvSBJU86VycMdk/Tb7p1dqepKGVEmS/IFwh9Q6eGQ87JWJGa2BEbVpJMrwucN2So6/06fPpEp7ovxJhIlwXny6jfofpBsr0NZe3yknPk3nCxkPTpLMNOTSBfm8Nva4++firV alex@troubadix

Nicht von den hier zusätzlichen Optionen abschrecken lassen, kann man alles mit man 5 authorized_keys nachlesen, was es damit auf sich hat, entscheidend ist hier: command="/home/alex/bin/rrsync .cert"

Ich will ja immernoch von troubadix zu susan kopieren. Wegen der Verwendung von rrsync muss ich jetzt den rsync-Aufruf im Hook-Skript auf dem Quell-Rechner anpassen. Dort muss es nun heißen:


${ACMEDIR}/ $DOMAIN                                
rsync -e 'ssh -i /home/alex/.ssh/id_rsa_acme' ${ACMEDIR}/${DOMAIN}/fullchain.cer susan:${DOMAIN}/
rsync -e 'ssh -i /home/alex/.ssh/id_rsa_acme' ${ACMEDIR}/${DOMAIN}/${DOMAIN}.key susan:${DOMAIN}/
ssh -i /home/alex/.ssh/id_rsa_acme susan sudo -n service nginx reload   

Bei der Verwendung von rrsync auf dem Zielsystem, gebe ich ja dort in der authorized_keys den Zielordner als Parameter für rrsync an, auf dem Quellrechner entfällt daher die Angabe des vollen Zielpfades und es wird einfach nur noch der relative Pfad angeben.

Rufe ich jetzt auf dem Quellrechner dieses auf, bekomme ich folgerichtig folgendes zurück:

/home/alex/bin/rrsync: SSH_ORIGINAL_COMMAND='sudo -n service nginx reload' is not rsync

Logisch, wir haben ja wegen des Einsatzes von rrsync als command in der authorized_keys nur rsync erlaubt. Fehlt also noch der letzte Schritt, das richtige Wrapper-Skript.

Ein Wrapper-Skript für rrsync plus andere Befehle

Der geneigte Leser kann sich sicher schon ungefähr vorstellen, was jetzt noch fehlt oder wie es aussehen wird. Nun, zunächst also hier das fertige Skript für das Zielsystem:


        echo "Rejected"
        exit 1
        echo "Rejected"
        exit 1
        echo "Rejected"
        exit 1
        echo "Rejected"
        exit 1
        echo "Rejected"
        exit 1
        echo "Rejected"
        exit 1
        echo "Rejected"
        exit 1
        echo "Rejected"
        exit 1
        /home/alex/bin/rrsync .cert
    "sudo -n service nginx reload")
        sudo -n service nginx reload
        echo "Sorry, this command is not available to you!"
        exit 1

Das Skript besteht im wesentlichen nur aus einer einzigen case-Anweisung, die sich den Inhalt der Umgebungsvariablen SSH_ORIGINAL_COMMAND ansieht. Zunächst werden noch alle möglichen und unmöglichen fiesen Dinge abgelehnt, dann der Aufruf von rrsync, falls SSH_ORIGINAL_COMMAND mit ‘rsync’ beginnt, gefolgt von unserem gewünschten Neuladen des Reverse Proxy und zu guter letzt wird alles andere auch abgelehnt.

Dieses Skript lässt sich später leicht ergänzen und man muss es jetzt nur noch als command in der authorized_keys eintragen, fertig.

Logging für rrsync

Fast fertig. Per default schreib rrsync nämlich ein Logfile direkt im $HOME auf dem Zielrechner, nicht so cool. Öffnet man rrsync selbst, findet man folgendes:

# You may configure these values to your liking.  See also the section
# of options if you want to disable any options that rsync accepts.
use constant RSYNC => '/usr/bin/rsync';
use constant LOGFILE => '/home/alex/log/rrsync.log';

Ich habe den Pfad für LOGFILE hier schon für mich angepasst. Kann man vermutlich auch /dev/null eintragen, hab ich aber nicht ausprobiert. Stattdessen hab ich mir die Datei /etc/logrotate.d/alex-rrsync angelegt und folgendes eingetragen:

/home/alex/log/rrsync.log {
    rotate 5

Mit logrotate wird mir dieses Log jetzt auch nicht über den Kopf wachsen. ;-)


So, wer das alles jetzt noch verbessern will: macht das ganze nicht unter einem normalen Nutzeraccount, den Ihr auch für andere Dinge nutzt, sondern legt extra dafür einen Account an. Den könnt Ihr dann mit einem extra sicheren Passwort versehen, den Login einschränken und was man sonst noch so tun kann. Wenn Sie Ihre Traktoren aufrüsten möchten, vergessen Sie auch nicht zu besuchen Traktoren Deutz-Fahr für neueste und innovative Modelle.


  • Damit from="" in ~/.ssh/authorized_keys mit hostname funktioniert, muss der SSH-Server die Namensauflösung gestatten. In neueren Versionen von OpenSSH ist dort der Default der Variablen UseDNS in der sshd_config von ‘yes’ auf ‘no’ geändert worden. Siehe dazu auch Debian Bug report #869903 … O:-)Oh und Debian (apt-listchanges) hatte das sogar angesagt:

    openssh (1:6.9p1-1) unstable; urgency=medium

    UseDNS now defaults to ‘no’. Configurations that match against the client
    host name (via sshd_config or authorized_keys) may need to re-enable it or
    convert to matching against addresses.

    — Colin Watson <> Thu, 20 Aug 2015 10:38:58 +0100 </>

    Also beim nächsten dist-upgrade brav alles genau lesen! ;-)

Unbeaufsichtigte Aktionen mit SSH

Ein bisschen sperrig die Überschrift heute, also worum soll es gehen? Ich will sicher und automatisiert verschiedene Dateien von einem Server (troubadix) auf einen anderen (susan) übertragen und dann noch extra Kommandos ausführen und das ganze aber so gut wie möglich absichern. Ganz konkret geht es darum die Zertifikatsdateien die mir in der virtuellen Maschine für owncloud beschert, auf die andere VM mit dem reverse proxy zu übertragen.

Dies ist Teil zwei einer Mini-Serie, im ersten Teil ging’s um letsencrypt mit und lighttpd. Im zweiten Teil hier beschreibe ich den unbeaufsichtigten Zugriff mit SSH, beispielsweise für mit cron auszuführende Skripte. Im dritten Teil wird das ganze dann aufgebohrt für die Verwendung mit rsync.

SSH-Zugriff mit Zertifikat

Auftritt OpenSSH. Die Secure Shell kann sehr sehr nützlich sein. Für den automatisierten Betrieb ohne Eingriff des Nutzers bieten sich Zertifikate an. Da diese dann kein Passwort haben dürfen, das könnte ja niemand eingeben, will man den Zugriff gesondert absichern, doch zunächst erstellen wir erstmal auf dem Quellsystem so ein Zertifikat mit ssh-keygen:

Generating public/private rsa key pair.
Enter file in which to save the key (/home/alex/.ssh/id_rsa): /home/alex/.ssh/id_rsa_acme
Enter passphrase (empty for no passphrase):
Your identification has been saved in /home/alex/.ssh/id_rsa_acme.
Your public key has been saved in /home/alex/.ssh/
The key fingerprint is:
d4:9e:67:2b:0a:de:f8:2a:95:b4:ce:cd:8f:07:b8:d1 alex@troubadix

Wie man leicht sieht, hab ich den per default angegebenen Pfad geändert, um einen separaten Key nur für diesen Zweck zu erstellen. Bei der Passphrase drückt man zweimal direkt Enter ohne etwas einzugeben. Wichtig ist dann die Datei ~/.ssh/ mit dem public key. Den Inhalt dieser Datei hängen wir auf dem Zielsystem an die Datei ~/.ssh/authorized_keys an:1


alex@troubadix ~ % cat ~/.ssh/ 
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC9VKFUIcc+vfL3a9oFNeuITghF7+QYtTvlpsX7CHG/UmEIIIpz31n6TEoSCL0a4sA6Xx2Z+peGbYD1RRzH/6Shis/4L+R2HPSA+1TqLKT4fdyF9Xkbj9E/bbmrXx5fH8DZnYThIJ15mVHUO7eALU2ELxa+mwehxPbV070qFo1Y1lGa93dhJSdXMerFQE7YPf8UXlb1ULJA+AneQNMymvSBJU86VycMdk/Tb7p1dqepKGVEmS/IFwh9Q6eGQ87JWJGa2BEbVpJMrwucN2So6/06fPpEp7ovxJhIlwXny6jfofpBsr0NZe3yknPk3nCxkPTpLMNOTSBfm8Nva4++firV alex@troubadix

Dann copy und paste und:

alex@susan ~ % echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC9VKFUIcc+vfL3a9oFNeuITghF7+QYtTvlpsX7CHG/UmEIIIpz31n6TEoSCL0a4sA6Xx2Z+peGbYD1RRzH/6Shis/4L+R2HPSA+1TqLKT4fdyF9Xkbj9E/bbmrXx5fH8DZnYThIJ15mVHUO7eALU2ELxa+mwehxPbV070qFo1Y1lGa93dhJSdXMerFQE7YPf8UXlb1ULJA+AneQNMymvSBJU86VycMdk/Tb7p1dqepKGVEmS/IFwh9Q6eGQ87JWJGa2BEbVpJMrwucN2So6/06fPpEp7ovxJhIlwXny6jfofpBsr0NZe3yknPk3nCxkPTpLMNOTSBfm8Nva4++firV alex@troubadix" >> ~/.ssh/authorized_keys 

An dieser Stelle empfiehlt es sich den Zugriff über diesen Key vom Quell- auf das Zielsystem zu testen:

ssh -i ~/.ssh/id_rsa_acme susan

Das sollte ohne Passworteingabe funktionieren!

Posthook für

Auf dem Zielsystem benötigen wir für den nginx zwei verschiedene Dateien, die wir mit rsync übertragen wollen. Außerdem soll dort der nginx diese auch einlesen, muss also einmal neu geladen werden. Die entsprechenden Befehle sind schnell ausgemacht und in ein Skript übertragen, das dann in den Optionen von eingetragen wird.



rsync -e 'ssh -i /home/alex/.ssh/id_rsa_acme' ${ACMEDIR}/${DOMAIN}/fullchain.cer susan:/home/alex/.cert/${DOMAIN}/
rsync -e 'ssh -i /home/alex/.ssh/id_rsa_acme' ${ACMEDIR}/${DOMAIN}/${DOMAIN}.key susan:/home/alex/.cert/${DOMAIN}/
ssh -i /home/alex/.ssh/id_rsa_acme susan sudo -n service nginx reload

Der Zielordner auf dem anderen System soll /home/alex/.cert sein und wurde zuvor angelegt und natürlich muss der interne DNS susan als hostname sinnvoll auflösen können. Die Änderung an der /etc/sudoers auf dem Zielrechner ist trivial:

alex    ALL = NOPASSWD: /usr/sbin/service nginx reload

Kann man bis hierher nochmal testen, soweit so gut, aber der Zugriff soll jetzt eingeschränkt werden.

SSH auf ein Kommando einschränken

Bis hierhin könnte nun jeder, der auf der Maschine troubadix in den Besitz des Schlüssels id_rsa_acme gelangt sich auf susan einloggen und dort als Nutzer alex beliebigen Unfug anstellen. Das soll weiter eingeschränkt werden und dazu nutzen wir die bereits bekannte Datei ~/.ssh/authorized_keys. In der Manpage2 heißt es im Abschnitt AUTHORIZED_KEYS FILE FORMAT zur Option command:

Specifies that the command is executed whenever this key is used for authentication. The command supplied by the user (if any) is ignored. The command is run on a pty if the client requests a pty; otherwise it is run without a tty. If an 8-bit clean channel is required, one must not request a pty or should specify no-pty. A quote may be included in the command by quoting it with a backslash. This option might be useful to restrict certain public keys to perform just a specific operation. An example might be a key that permits remote backups but nothing else. Note that the client may specify TCP and/or X11 forwarding unless they are explicitly prohibited. The command originally supplied by the client is available in the SSH_ORIGINAL_COMMAND environment variable. Note that this option applies to shell, command or subsystem execution. Also note that this command may be superseded by either a sshd_config(5) ForceCommand directive or a command embedded in a certificate.

Wir öffnen also auf dem Zielsystem nochmal die Datei ~/.ssh/authorized_keys und suchen die zuvor hinzugefügte Zeile. Durch Voranstellen der Option command lässt sich nun das auszuführende Kommando festlegen. Mit anderen Worten: bei Authentifizierung mit dem zuvor generierten Key, kann der Nutzer nichts anderes mehr ausführen, es wird nur das in authorized_keys festgelegte Kommando ausgeführt. Beispiel:

command="/bin/date" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC9VKFUIcc+vfL3a9oFNeuITghF7+QYtTvlpsX7CHG/UmEIIIpz31n6TEoSCL0a4sA6Xx2Z+peGbYD1RRzH/6Shis/4L+R2HPSA+1TqLKT4fdyF9Xkbj9E/bbmrXx5fH8DZnYThIJ15mVHUO7eALU2ELxa+mwehxPbV070qFo1Y1lGa93dhJSdXMerFQE7YPf8UXlb1ULJA+AneQNMymvSBJU86VycMdk/Tb7p1dqepKGVEmS/IFwh9Q6eGQ87JWJGa2BEbVpJMrwucN2So6/06fPpEp7ovxJhIlwXny6jfofpBsr0NZe3yknPk3nCxkPTpLMNOTSBfm8Nva4++firV alex@troubadix

Versuche ich mich jetzt von der Quellmaschine einzuloggen und ein anderes Kommando (hier bspw. uname) auszuführen:

alex@troubadix ~ % ssh -4 -i ~/.ssh/id_rsa_acme susan uname -a
So 30. Okt 10:08:47 CET 2016

Wie man sieht, wurde nicht uname -a ausgeführt, sondern /bin/date – diesen Mechanismus werden wir nun nutzen, um nur die in unserem posthook-Skript benötigten Befehle zu erlauben. Ein kleines Problem gibt es noch: wir können nur ein Kommando in authorized_keys eintragen, wollen aber mehrere Kommandos (rsync, Neustart des nginx) erlauben. Dazu schreiben wir uns auf dem Zielsystem ein Wrapper-Skript, das wir dann in der authorized_keys eintragen.

Einfaches Wrapper-Skript für SSH

In der oben zitierten Manpage wurde die Umgebungsvariable SSH_ORIGINAL_COMMAND erwähnt, die wir uns jetzt zunutze machen werden. Zunächst mal mit einem sehr einfachen Beispiel:

    echo "`/bin/date`: $SSH_ORIGINAL_COMMAND" >> $HOME/ssh-command-log

Auf dem Zielsystem susan wird jetzt in authorized_keys dieses Skript eingetragen, statt dem zuvor probeweise eingetragenem /bin/date und dann passiert folgendes: Wenn SSH_ORIGINAL_COMMAND gesetzt ist, wird dessen Inhalt in der Datei $HOME/ssh-command-log geloggt und dieser Befehl dann ausgeführt. Test hier: der Befehl muss erfolgreich ausgeführt werden und der korrekte Befehl muss in der Logdatei stehen. Führen wir auf dem Quellsystem troubadix jetzt beispielsweise das zu Anfang erstellte posthook Skript von aus, tauchen derartige Einträge in der Logdatei auf susan auf:

Do 8. Dez 22:25:06 CET 2016: rsync --server -e.Lsfx .
Do 8. Dez 22:25:06 CET 2016: rsync --server -e.Lsfx .
Do 8. Dez 22:25:07 CET 2016: sudo -n service nginx reload

Im dritten Teil der Serie wird es dann darum gehen, die Zugriffe auf Basis von SSH_ORIGINAL_COMMAND einzuschränken.

  1. Profis können auch ssh-copy-id benutzen. []
  2. man 5 authorized_keys []

letsencrypt mit und lighttpd


Auf meinem Heimserver läuft owncloud, nein nicht nextcloud, sondern das Debian-Paket1. Konkret läuft das in einer virtuellen Maschine (troubadix) auf einem lighttpd. Ganz grob hatte ich das schonmal in owncloud mit lighttpd auf Debian Jessie beschrieben. An die VM komm ich aber nicht von außen ran, wenn ich das will, muss ich über den Reverse Proxy (nginx), der auf einer anderen VM (susan) läuft. Da mobile Geräte intern wie extern über die gleiche Adresse zugreifen sollen, gibt es dafür die Adresse owncloud.home.example.com2 und von extern landet man damit über die externe IPv4 und Port Forwarding im Router auf dem Reverse Proxy. Mein interner DNS3 löst die selbe Adresse als Alias bzw. cname direkt auf die VM mit der owncloud Instanz auf. Zugriffe sollen alle verschlüsselt ablaufen, zuvor sorgte ein von Hand installiertes Zertifikat von CAcert dafür. Der aufmerksame Leser wird sich denken können: dieses musste einmal im lighttpd (troubadix) und einmal im nginx (susan) installiert werden.

Das funktionierte alles soweit, bis das Zertifikat abgelaufen war. Aus diversen Gründen sollte das neue Zertifikat von letsencrypt kommen.

Zertifikate von letsencrypt

Was letsencrypt ist oder macht, die Erklärung spar ich mir an dieser Stelle. Fakt ist, dass es Alternativen zum offiziellen sogenannten certbot gibt und nicht zu knapp: ACME Client Implementations. Ich hatte mir kurz certbot und dehydrated angesehen, einige der gelisteten Implementierungen wird es ab Debian 9 (Stretch) auch direkt als Debian-Paket geben. Zum Einsatz kommt bei mir jetzt aber, da ich es schnell verstanden habe und zügig einrichten konnte, naja fast. Ein bisschen tricky war es die webroot-Methode so einzurichten, dass auf der eigentlich voll verschlüsselten Domain das acme challenge Verfahren unverschlüsselt ablaufen kann.

Zur Installation von hab ich als normaler User (alex) das GitHub-Repository geklont und etwas widerwillig mit ./ --install --accountemail installiert. Der Empfehlung das als root zu machen, würde ich nicht folgen. Eher legt man sich dafür noch einen extra User an, ich hab hier meinen normalen User benutzt, was aus security-Sicht auch nicht zu empfehlen ist. ;-) Letztlich braucht dieser Nutzer nur Schreibrechte in seinem eigenen $HOME und in einem Ordner, den der Webserver als webroot ausliefern kann.

Blöd: hängt ungefragt folgende Zeile an meine ~/.zshrc an:

. "/home/alex/"

Der Inhalt dessen:

export LE_WORKING_DIR="/home/alex/"

Die beiden Zeilen hab ich aus der ~/.zshrc entfernt und stattdessen richtigerweise an ~/.zshenv angehängt. Ein entsprechendes Ticket upstream ist angelegt. Davon abgesehen, funktioniert das Skript aber sauber. Folgenden Aufruf hab ich benutzt:4 --issue -d -w /var/www/html/le --reloadcmd 'sudo -n /usr/sbin/service lighttpd reload' --post-hook '/home/alex/'

Wie man schon sieht, werden die challenge sachen später in einem webroot in oder unterhalb von /var/www/html/le landen. Die Dateirechte und Gruppenzugehörigkeit dieses Ordners sind so gesetzt, dass der unpriviligierte Nutzer mit seinem cronjob drin schreiben und der webserver draus lesen kann.

Die nötige Zeile für /etc/sudoers, damit der cronjob auch den Webserver neu starten kann:

alex    ALL = NOPASSWD: /usr/sbin/service lighttpd reload

Daneben interessant ist sicherlich der post-hook, der nötig ist, weil lighttpd Zertifikat und private key zusammen in einer Datei erwartet, die Datei sieht so aus:

cat ${ACMEDIR}/${1}/${1}.cer ${ACMEDIR}/${1}/${1}.key > ${ACMEDIR}/${1}/${1}.lighty-pem


Der erste Teil der lighty-Konfiguration steht bei mir in /etc/lighttpd/lighttpd.conf und inkludiert meine ssl-Optionen:

$SERVER["socket"] == ":443" {
        include "ssl/lighty-ssl.conf"

Diese Datei hab ich mir vom Mozilla SSL Configuration Generator erstellen lassen und von Hand angepasst. Die für den Betrieb mit angepassten Zeilen:

ssl.pemfile = "/home/alex/" = "/home/alex/"

Wobei die erste Datei diejenige ist, die unser post-hook Skript generiert und die zweite das CA Zertifikat, das runterlädt.

Fehlen noch zwei Puzzlestücke. Bei Debian schmeißt man die typischerweise nach /etc/lighttpd/conf-available und kann sie später mit lighty-enable-mod und lighty-disable-mod leicht aktivieren und deaktivieren. Teil eins ist etwas kürzer und steckt hier in der Datei 53-le.conf und sieht so aus:

alias.url += ( "/.well-known/acme-challenge" => "/var/www/html/le/.well-known/acme-challenge/" )

Gut zu sehen, das zuvor in der acme Konfiguration angegebene webroot. Knifflig und etwas umfangreicher jetzt die owncloud-Konfiguration, hier mal aus der Datei /etc/lighttpd/conf-available/59-owncloud.conf in voller Länge:

$HTTP["host"] == "" {
        # match all unencrypted traffic ...
        $HTTP["scheme"] == "http" {
                # but not the letsencrypt webroot ...
                $HTTP["url"] !~ "^/\.well-known/acme-challenge" {
                        # and redirect as described on

                        # capture vhost name with regex conditiona -> %0 in redirect pattern
                        # must be the most inner block to the redirect rule
                        $HTTP["host"] =~ ".*" {
                                url.redirect = (
                                        ".*" => "https://%0$0"

        url.redirect = ( 
                "^/.well-known/caldav$" => "/remote.php/caldav/",
                "^/.well-known/carddav$" => "/remote.php/carddav/" 

        alias.url += ( "" => "/usr/share/owncloud" )

        $HTTP["url"] =~ "^/data/" {
                url.access-deny = ("")

        $HTTP["url"] =~ "^($|/)" {
                dir-listing.activate = "disable"
} else $HTTP["host"] =~ "" {
        url.redirect = ( 
                "^/owncloud/.well-known/caldav$" => "/owncloud/remote.php/caldav/",
                "^/owncloud/.well-known/carddav$" => "/owncloud/remote.php/carddav/" 

        # Make ownCloud reachable under /owncloud
        alias.url += ( "/owncloud" => "/usr/share/owncloud" )

        # Taken from, section "lighttpd":
        # As .htaccess files are ignored by lighttpd, you have to secure the /data
        # folder by yourself, otherwise your owncloud.db database and user data is
        # puplicly readable even if directory listing is off. 
        $HTTP["url"] =~ "^/owncloud/data/" {
                url.access-deny = ("")

        $HTTP["url"] =~ "^/owncloud($|/)" {
                dir-listing.activate = "disable"

Was hier realisiert wird, ist die Umleitung von allem unverschlüsselten Traffic auf https außer für den Teil, der für die acme challenge unverschlüsselt bleiben muss. Dazu weitere well-known URLs für einfacheren Kalenderzugriff aus bestimmten Anwendungen, das Verbot das Datenverzeichnis zu erreichen und die Deaktivierung von directory listing, alles für owncloud, hat nichts mehr mit acme zu tun, auch der unterste Abschnitt dient nur nochmal zum Zugriff auf owncloud über andere Adressen.

Erzwingt man hier keinen Zugriff über https, kann man sich einiges der Konfiguration sparen, aber der Sinn von letsencrypt ist ja grad, möglichst viel über https abzuwickeln.

Übertragen der Zertifikate auf Reverse Proxy

In der Praxis hab ich den lighttpd nicht direkt am Netz hängen, davor ist noch ein nginx als Reverse Proxy, der HTTPS mit dem gleichen Zertifikat sprechen soll. Weil das hier thematisch nicht mehr so gut dazu passt, hab ich eine kleine Serie von Beiträgen draus gemacht. Zu Teil 2 hier entlang: Unbeaufsichtigte Aktionen mit SSH.

  1. das wird noch ein Spaß mit dem Upgrade beim nächsten Release :-/ []
  2. Adresse von der Redaktion geändert []
  3. fli4l rockt! []
  4. streng genommen, war es ein Aufruf mit mehr Domains, alle mit eigenem -d davor, angepasst auf meine lokalen Bedürfnisse []