The openSUSE forums also support the NNTP protocol (usually referred to as "news"). There are plenty of GUI news readers out there (thunderbird, knode, pan, ...), but as I'm using mutt to read my emails as well as irssi for IRC in screen sessions (in urxvt, I wanted a console based NNTP client for that as well. (No, I don't use lynx or w3m for web browsing, I'm not a masochist ;).)

Hence I installed trn.

Here is how to set it up to access the openSUSE forums with it:

1. Obviously, first install trn:
   zypper install trn
2. then run rtin once, which will give you an error message and exit, but that will create its configuration file tree in ~/.tin:
   rtin
3. next, edit the configuration file ~/.tin/newsrctable and add the following line:
   forums.opensuse.org /home/XXX/.tin/foo foo
   (where you replace /home/XXX with your actual home directory)
   If you are not fluent with text editors, you can also simply execute the following command from a shell (just copy/paste it):
   echo "forums.opensuse.org $HOME/.tin/foo foo" >> ~/.tin/newsrctable
4. now we can actually run rtin to connect to the openSUSE forums:
   rtin -a -g foo
   (note that the -a flag turns on color support, and -g foo tells rtin to connect to the server we configured as "foo" in ~/.tin/newsrctable)
5. you are now greeted with an (almost) empty screen: press the y key (yank in/out) to get a list of all the forums in order to subscribe to those that are of interest to you: simply use the arrow keys to scroll the list and press the s key (subscribe) to subscribe those you want to follow

I use an encrypted USB stick to carry credentials and data for production servers I look after when I’m on call. One requirement was portability between my work (Windows) and home (GNU/Linux) desktops, so TrueCrypt came to mind. I packaged it all up an applied some patches to fix compiler issues and warnings. The TrueCrypt license, however, is not OSI-approved, and as such the program cannot be built in the openSUSE build service (see blacklist, discussion).

I almost forgot about the whole thing until I upgraded the package for new dependencies in the upcoming release of openSUSE 11.4. I talked with people over at packman, a popular 3rd-party repository for software not included in openSUSE proper for one reason or another. We analysed the license a bit and concluded that if we shipped binaries built from non-pristine sources, the product would have to be re-branded as per the requirements of their license. I am usually pragmatic about these things as long as FLOSS and non-FLOSS licences can be adhered to, but didn’t want to go the route Debian took with Firefox et al.

We contacted the TrueCrypt developers on this issue, we’ll see what comes out of that. Until then, if someone wants to build this package, here is what you need:

truecrypt.spec
truecrypt.desktop
truecrypt-tc_token_err.patch
truecrypt-NULL_PTR-redefinition-warning.patch
truecrypt-undefined-operation-warning.patch

I'm feeling very lucky today. Why? Because in a few hours I'll be getting on a plane to Bengaluru, India and attending conf.kde.in. Pradeepto has been asking me for years to look outside the cosy confines of the US-Europe Axis of KDE, and thanks to my role in the openSUSE Boosters team, this has finally become possible.

I'll be giving a talk on contributing to KDE in the openSUSE project and a long talk/practical workshop on using the openSUSE Build Service as used by openSUSE, Novell, Dell, Intel, Nokia, Broadcom and Cray, to spread free software: your own, update existing software on openSUSE, or package for it and for many other distros at one go. But mainly I'm looking forward to meeting the people who make up a whole side of KDE. So if you haven't made up your mind what you're doing next week, how about coming to the RV College of Engineering in Bengaluru?

Like many others,

PS: I'm bringing a load of openSUSE loot to give away, so just look for the guy staggering under the huge carton!

OpenSUSE bietet seit einigen Versionen die Möglichkeit bei der Installation die Festplatte komplett zu Verschlüsseln. In Anbetracht der großen Menge an Daten macht dies heutzutage nicht nur bei Laptops, sondern auch bei stationären Rechnern Sinn. Wird der Rechner aber als Server — ohne Tastatur und Monitor — betrieben stört hierbei allerdings die notwendige Passworteingabe beim Starten des Rechners. Glücklicherweise bietet LUKS aber die Möglichkeit diese auf einem USB-Stick zu speichern, womit auch bei solchen Maschinen ein komfortabler Start möglich ist.

Achtung: Diese für openSUSE 11.3 erstellte Anleitung funktioniert bis einschließlich openSUSE 13.1. Auf openSUSE 13.2 und openSUSE Leap 42.1 habe ich sie nicht getestet. Auf openSUSE Leap 42.2 funktioniert sie nicht mehr. Es gibt einen neuen Mechanismus, welchen ich, sobald ich ihn ausführlich getestet habe, verbloggen und hier verlinken werde.

Ist ein USB-Stick als Schlüssel sicher?

Sicherheit ist immer relativ zur Bedrohung zu sehen. Auch beim USB-Stick stellt sich also die Frage wovor er schützen soll. Beim stationär zuhause stehenden Rechner hat die Verschlüsselung vor allem eine Funktion, sie schützt die Daten wenn die betroffen Festplatten mal das eigene Haus verlassen. Hierbei gibt es im Prinzip nur zwei Fälle. Stellt sich eine Platte während der Garantiezeit als defekt heraus so erspart einem die Verschlüsselung das heutzutage sehr zeitaufwendige Löschen der Platte. Wird die Festplatte entwendet, so ist sie ohne den USB-Stick, der natürlich in diesem Fall nicht im Rechner gesteckt haben darf, auch nicht auszulesen.

Ein großer Vorteil des USB-Sticks besteht hier darin, dass er sehr lange Passwörter ermöglicht. Möchte man lange Passwörten auf klassischem Weg verwenden kommt man um ein Aufschreiben des Passworts oft auch nicht herum. Außerdem gewinnt man eine Möglichkeit die Herausgabe des Passworts zu verweigern, sollte man je dazu aufgefordert werden. Bei einem langen Passwort welches man nie getippt hat ist die Chance sich zu erinnern nicht existieren. Auch hier gilt natürlich, der USB-Stick darf dann nicht trivial dem Rechner zuzuordnen sein.

Die Anleitung

Backup

Unter openSUSE ist es hierbei wichtig den Anfang des initrd und kernel-Namens zu ändern, da diese vom Befehl mkinitrd sonst dennoch aktualisiert werden.

cp /boot/initrd-2.6.34-12 /boot/safe-initrd-2.6.34-12
cp /boot/vmlinuz-2.6.34-12 /boot/safe-enable-vmlinuz-2.6.34-12

title SafetyNet -- openSUSE 11.3 - 2.6.34-12
    root (hd0,0)
    kernel /safe-vmlinuz-2.6.34-12 root=/dev/system/root resume=/dev/system/swap splash=silent quiet showopts vga=0x317
    initrd /safe-enable-initrd-2.6.34-12

Anlegen des Schlüssels

mkfs.ext2 -L keystick /dev/sdb

tune2fs -L keystick /dev/sdb

Das Label kann natürlich frei gewählt werden. Es dient später zur Identifizierung des Sticks. Dies hat zwei Vorteile:

• Der USB-Stick unabhängig von hinzugekommenen oder entfernten Datenträgern gefunden
• Anders als bei der Identifizierung über die ID des Sticks kann man einen zweiten Stick mit gleichem Label als Backup verwenden. Ich recycle gerne nutzlose Werbegeschenke für diese Aufgabe. Sollte mal eines kaputt gehen spare ich mir das Zeitaufwendige zurückspielen des Backups der ganzen platte, da ich den Schlüssel ja noch von einem zweiten USB-Stick laden kann.

Anschließend sollte ein Passwort generieren und auf dem USB-Stick hinterlegen. Meine bevorzugte Methode ist diese:

pwgen -s 1024 1 > /media/keystick/keyfile

Nun kann man den erzeugten Schlüssel der verschlüsselten Partition hinzufügen. Leider verhält sich LUKS leicht unterschiedlich was interaktiv eingegebene Schlüssel und Schlüsseldateien angeht. Deshalb müssen wir unseren Schlüssel "interaktiv" eingeben. Hierzu erzeugt man zunächst eine Datei welche eine Zeile mit dem bei der Installation gewählten Schlüssel und eine mit dem neuen enthält.

cat oldkey /media/keystick/keyfile > tmp

cryptsetup luksAddKey /dev/sda2 < tmp

rm tmp

Um zu testen ob der Schlüssel korrekt hinzugefügt wurde kann man probehalber einen leeren Schlüssel hinzufügen. LUKS ist schlau genug diesen Schlüssel nicht wirklich aufzunehmen:

cryptsetup luksAddKey /dev/sda2 < /media/keystick/keyfile

Erstellen der neuen Initramdisk

usb_storage scsi_mod

Um LUKS den Schlüssel zu übergeben benötigt man ein Skript welches ihn vom USB-Stick liest. Dies kann an einer beliebigen Stelle im Dateisystem liegen, es wird beim erstellen der Initramdisk in diese gepackt:

#!/bin/sh

STICK=/dev/disk/by-label/keystick
FSTYPE=ext2
slumber=150
modprobe usb-storage 1>&2
modprobe scsi_mod 1>&2
mkdir /keystick 1>2&
sleep 5 1>2&

while [ $slumber -gt 0 ] && [ ! -e "$STICK" ]; do
      sleep 1
      slumber=$(( $slumber - 1 ))
done
if ! mount -t $FSTYPE -r $STICK /keystick ; then
   $( echo 'FAILED!!!' ) 1>2&
   echo ''
   exit 1
fi

cat /keystick/keyfile

umount /keystick 1>2&

Damit LUKS weiß, dass es den Wert von einem Skript erhält muss die Datei /etc/crypttab angepasst werden:

cr_sda2         /dev/sda2       none    initrd,luks,keyscript=/root/keyscript.sh

• Ist keyscript gesetzt ist keine interaktive Eingabe mehr möglich. Deshalb sollte man die alte Initramdisk (welche die alte Konfiguration enthält) vorher sichern.
• Der Wert initrd ist notwendig, da openSUSE bei der Generierung der Initramdisk sonst nicht merkt, dass es das Keyscript mit einpacken muss.

Zu guter letzt kann durch den Aufruf von mkinitrd die neue Initramdisk erstellt werden. Ein Neustart sollte den Schlüssel dann vom USB-Stick lesen anstatt diesen interaktiv zu erwarten.

Hat man die neue Konfiguration hinreichen getestet kann man den bei der Installation vergebenen Schlüssel aus LUKS entfernen und die gesicherte Initramdisk löschen.

Eine Anmerkung zur Distributionsaktualisierung

Diese Anleitung habe ich ursprünglich anhand von openSUSE 11.3 erstellt. Sie gilt aber auch für aktuellere Versionen bis 13.1. Auf openSUSE Leap 42.2 funktionierte diese methode aber nicht! Auf neuere Versionen kann man über das normale DVD-Update aktualisieren. Hierbei muss man allerdings die verschlüsselte Partition über einen eingetippten Schlüssel öffnen. Hierzu hilft es den bei der initialien Installation verwendeten Schlüssel nicht deaktiviert zu haben, oder aber temporär per cryptsetup luksAddKey einen kürzeren Schlüssel hinzuzufügen. Getestet habe ich auf diese Weise das Update von 11.3 auf 11.4 und von 11.4 auf 12.1. Der Installer warnt einen zwar, dass es Probleme geben kann, wenn man Partitionen per Kernel Device Name mountet, dies hat sich aber bisher nicht als Problem herausgestellt.

Quellen

Da die Literatur — was openSUSE angeht — zu diesem Thema leider noch sehr dürftig ist habe ich mich vieler Quellen bedient, von denen ich hier nur die wichtigsten nennen möchte:

• http://forum.ubuntuusers.de/topic/luks-root-partition-mit-schluessel-auf-usb-st/#post-1928847 lieferte die Vorlage für mein Keyscript.
• http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions hilft enorm beim Verständnis.
• http://forums.fedoraforum.org/showthread.php?t=241942 zeigt im Prinzip den ganzen Vorgang, funktioniert leider nicht 1:1 für openSUSE.
• http://wejn.org/how-to-make-passwordless-cryptsetup.html zeigt mehrere Variationen des Themas, aber passt auch nicht direkt auf openSUSE.
• http://raftaman.net/?p=300 ist inspirierend, löst aber nicht ganz das gleiche Problem (der verwendete USB-Stick ist cool).
• https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS_for_dm-crypt#Remote_unlocking_of_the_root_.28or_other.29_partition liefert Grundlagen, wenn man dies möchte.