Keychain: Alternative zu Gnome-Keyring um SSH-Schlüssel zwischen Logins zu verwalten


An Gnome ist nicht alles schlecht. Das merkt man spätestens dann, wenn man sich näher mit der Situation von Archivmanagern wie Squeeze oder Xarchiver befasst und diese File-Roller gegenüberstellt. Ähnlich verhält es sich mit Gnome-Keyring und Seahorse. Beide Anwendungen vereinfachen das Verwalten von Passwörtern, GPG- und SSH-Schlüsseln enorm.

Die Kehrseite der Medaille ist, bei einer reinen Fenstermanager-Lösung oder bei LXDE werden viele Gnome-Bibliotheken und Ballast mitinstalliert.

Ich habe bisher noch keine perfekte leichtgewichtige Lösung gefunden, die alle meine Wünsche erfüllt. Insbesondere ist das automatische Entsperren aller Schlüssel im Schlüsselring von Gnome eine große Erleichterung, die ich in dieser Form vielleicht noch bei KDE vermute. Ein leichtgewichtiges Pendant zu Seahorse und Co., das aktiv betreut wird – Fehlanzeige.

Keychain

Ich habe mich mal wieder im Wiki von Arch Linux umgesehen und diesen Eintrag zum Thema SSH-Keys gefunden. Schließlich habe ich mich dafür entschieden mir Keychain näher anzusehen, eine in Shell-Skript geschriebene Anwendung, die meinen Anforderungen am besten gerecht wird.

Bisher sah mein Umgang mit SSH-Schlüsseln so aus. Zuerst wurden sie mit ssh-keygen erzeugt und wie im Artikel zur Absicherung des SSH-Servers beschrieben, dann entweder mit Hilfe von Gnome-Keyring in meinem Schlüsselbund dauerhaft gespeichert oder auf der Konsole mit ssh-agent und ssh-add für die Dauer einer Sitzung entsperrt.

Der Vorteil von SSH-Schlüsseln ist, sie verbessern nicht nur die Sicherheit, sondern sie sind auch bequem zu benutzen. Einmal entsperrt und man kann sich bequem ohne Passworteingabe zu einem entfernten Rechner verbinden.

Keychains Vorteil gegenüber der manuellen Methode ist, dass automatisch beim Einloggen in den Terminal ssh-agent und ssh-add ausgeführt werden. Üblicherweise muss man nach jedem Ab- und Anmelden und Wechsel der Sitzung den SSH-Schlüssel erneut entsperren. Mit Keychain startet ein dauerhafter Prozess des ssh-agent, der für jede neue Sitzung wiederverwendet wird. Das heißt, einmal entsperrt lässt sich der Schlüssel bis zum nächsten Reboot ohne weitere Passworteingabe benutzen.

keychain --quiet id_pc1_rsa id_pc2_rsa
[ -z "$HOSTNAME" ] && HOSTNAME=`uname -n`
[ -f $HOME/.keychain/$HOSTNAME-sh ] && 
        . $HOME/.keychain/$HOSTNAME-sh
[ -f $HOME/.keychain/$HOSTNAME-sh-gpg ] && 
        . $HOME/.keychain/$HOSTNAME-sh-gpg

Dieser Code-Schnipsel wird entweder in der Datei ~/.bash_profile, oder wenn man ZSH benutzt in ~/.zshrc eingefügt. Keychain fügt automatisch die privaten SSH-Schlüssel id_pc1_rsa und id_pc2_rsa dem SSH-Agenten hinzu bzw. GnuPG-Agent, wenn dieser installiert sein sollte. Die Parameter für die laufende Sitzung werden standardmäßig in ~/.keychain/ gespeichert. Die Option –quiet sorgt noch dafür, dass nur Warnungen oder Fehlermeldungen ausgegeben werden, wenn man sich einloggt. Ansonsten würde eine ähnliche Meldung wie diese jedes Mal erscheinen.

* keychain 2.7.1 ~ http://www.funtoo.org
* Found existing ssh-agent: 2797
* Known ssh key: /home/apo/.ssh/id_pc1_rsa
* Known ssh key: /home/apo/.ssh/id_pc2_rsa

Fazit

Keychain ist eine leichtgewichtige Lösung um SSH-Schlüssel über Sitzungsgrenzen hinweg zu entsperren und bequem nutzen zu können. Auch für Cron-Jobs sicherlich eine nützliche Lösung. Das Handbuch man keychain ist empfehlenswert und informativ. Weitere Informationen gibt es wie immer in /usr/share/doc/keychain oder auf der Projektseite. Ich denke, der Gnome-Keyring und Seahorse sind weiterhin die bequemste Möglichkeit. Keychain ist für mich momentan jedoch ein sehr guter Ersatz auf einem leichtgewichtigen System.

Wie geht ihr mit dem Thema Passwörter und Schlüssel um?

Dwb und Jumanji: Zwei Webkit-Browser mit vi-ähnlicher Steuerung

Letzte Woche hat mich Georg auf einen interessanten Webkit-Browser namens Jumanji aufmerksam gemacht. Ich ergreife hier die Gelegenheit und stelle sowohl Jumanji als auch Dwb kurz vor. Beide setzen auf die Webkit-Engine und eine vi-ähnliche Steuerung und eignen sich als leichtgewichtige Browser-Alternative nicht nur für ältere Rechner.

Die Bilder stammen alle von meiner ArchLinux-Installation auf dem Inspiron 4000.

Jumanji

Jumanji ist ein minimalistischer WebKit-Browser, dessen Interface schlicht und platzsparend und deswegen auch sehr übersichtlich ist.

Die Bedienung lässt sich tatsächlich mit dem Stichwort vi-ähnlich auf den Punkt bringen. Genauso wie bei seinem berühmten Vorbild betritt man mit dem Doppelpunkt den Kommandomodus und kann von dort diverse Befehle aufrufen. Besonders praktisch ist es mit Hilfe von Tab-Vervollständigung von Befehl zu Befehl zu wechseln. Noch schneller geht es nur noch mit Tastenkürzeln, die man wie bei vi durch das „:map„-Kommando definieren kann.

Neue Tabs öffnet man entweder mit :tabopen oder mit der Taste t. Sie erscheinen in dezentem schwarz hinterlegt am oberen Bildschirmrand. Aktive erkennt man durch die geänderte Schriftfarbe. Interessant ist auch, dass man durch den Browserverlauf mit Tab-Vervollständigung navigieren kann. Mit der rechten Maustaste lässt sich ein kleines Menü aufrufen, um die Seite neu zu laden oder vor- und zurück zu wechseln.

Jumanji lässt sich bei Arch Linux aus dem AUR installieren. Wer yaourt benutzt, erledigt das mit:

yaourt -S jumanji-git

P.S.: Als Randnotiz fiel mir noch der Webseitengenerator der offiziellen Jumanji-Homepage auf. Hakyll ist eine Haskell-Bibliothek, um statische Webseiten zu generieren. Nur falls jemand dachte, es gäbe keine weiteren Alternativen zu den schon im Artikel und Kommentaren genannten Blogkompilierern. 🙂

Dwb

Im Gegensatz zu Jumanji existiert von Dwb seit kurzem eine offizielle Debianversion in Sid und Wheezy.

Dwb basiert ebenfalls auf der Webkit-Engine, besitzt vi-ähnliche Tastaturkürzel und Kommandos und zeichnet sich durch eine ebenso schlanke und effiziente Benutzerschnittstelle aus. Tatsächlich ähneln sich Jumanji und Dwb in vielerlei Hinsicht.

Der große Unterschied ist jedoch, Dwb hat das Konzept schon deutlich weiter entwickelt. Er ist umfangreicher, bietet mehr Kommandos und Funktionen. Genauso wie bei Jumanji lässt sich ein Adblock-Skript einbinden, darüber hinaus besteht aber auch die Möglichkeit Javascript oder Flash zu blockieren. Neue Tabs lassen sich mit O öffnen und d schließen. Lesezeichen werden mit M hinzugefügt und übersichtlich mit gB angezeigt und in einem neuen Tab geöffnet. Links kann per Tastatur gefolgt werden.

Besonders erwähnenswert ist auch, dass sich Einstellungen und Optionen auf einer Extraseite innerhalb des Browsers konfigurieren lassen und die Dokumentation in einem guten Zustand ist. Die Handbuchseite ist vorbildlich.

Die Suche funktioniert genauso wie bei Vi/Vim, indem die Taste / benutzt, der Suchbegriff eingegeben und schließlich n zur Vorwärtssuche ausgeführt wird.

Fazit

Mir gefallen tastaturgesteuerte, leichtgewichtige Webbrowser. Dwb hat bei mir aber gegenüber Jumanji die Nase vorn. Beide ähneln stark dem Vimperator-Plugin des Firefox, setzen aber stattdessen auf die Webkit-Engine und ordnen sich in die Reihe von Webbrowsern wie Vimprobable, Uzbl oder Surf ein.

Webkit-Browser sind nicht wirklich ungewöhnlich, was für die Engine spricht.

Der Speicherverbrauch und auch die Reaktionsgeschwindigkeit lässt sich am besten mit der von Surf vergleichen. Wie im letzten Test, habe ich wieder ps_mem.py als Maßstab benutzt.

Jumanji:

Private: 19MB + Shared: 1,3MB = 20,3MB

Dwb:

Private: 21,1MB + Shared: 2MB = 23,1MB

Die Startzeiten waren sogar noch schneller als bei Surf, obwohl das auch an dem selbstkompilierten ArchLinux-Paket liegen kann. Für die Zukunft werde ich dwb häufiger benutzen und denke, dass es eine gute Wahl war ihn in Debian aufzunehmen, da er sich durch seine umfangreiche vi-ähnliche Steuerung von den anderen Browsern in Debian positiv unterscheidet.

OS-tan: Mein verpasstes Internetphänomen

Scheinbar habe ich OS-tan vor einigen Jahren als Internethype verpasst, obwohl er sich bis heute wohl an verschiedenen Stellen fortsetzen soll und immer neue Kreationen hinzukommen. Kurz zusammengefasst ist OS-tan ein ursprünglich japanisches Phänomen, bei dem Betriebssysteme in Form von äußerst niedlichen Manga- und Animefiguren dargestellt werden und deren menschliche Eigenschaften die Stärken und Schwächen der Betriebssysteme symbolisieren sollen. Auf tomodachi.de findet sich ein interessanter und anschaulicher Artikel zu dem Thema.

Durch die Wunder des Internet bin ich nun nach all den Jahren auf diesen Begriff aufmerksam geworden. Danke K.Mandla. Sein kurzer Post aus dem Jahr 2007 hat mich auf die Seite von Jozu-kun, einer italienischen Künstlerin, gebracht, die eben diese OS-tans für Linuxdistributionen gestaltet hat.

Ich denke die Bilder sprechen für sich. Weitere Hintergrundbilder in besserer Qualität finden sich auf ihrer Desktop-Seite. Ist Debian wirklich so seriös? 🙂

Lizenz der Bilder: by-nc von Jozu-kun

Arch Linux
Debian
RedHat
Ubuntu

ConnochaetOS: Neue Software mit PKGBUILD selbst kompilieren

Ein Nachteil bei kleineren Linuxdistributionen ist, dass sie oftmals auf nur wenige Entwickler zurückgreifen können. Außerdem sind Webspace, Traffic und Zeit begrenzt und es fehlt einfach an Ressourcen, um jede verfügbare Software in einem Binärformat bereitstellen zu können.

Man kann dieses Problem in der Regel umgehen, indem man Werkzeuge wie Debians Alien oder Slitaz tazpkg benutzt, um Pakete fremder Distributionen in das eigene Format umzuwandeln. Das klappt bei kleineren Paketen oft sehr gut, man darf aber aber auch keine Wunder von so einer Transformation erwarten.

Bei Arch Linux und damit auch ConnochaetOS macht es keinen Sinn fremde Pakete umzuwandeln. Benutzer von Arch Linux werden mir sicher zustimmen, dass das Erstellen eigener Archpakete mit Hilfe von makepkg und dem Arch Build System(ABS) eine unkomplizierte Sache ist.

Um Pakete für ConnochaetOS zu bauen, empfand ich es am einfachsten mir das ABS zu installieren und die dort bereitgestellten PKGBUILDs an meine Bedürfnisse anzupassen.

pacman -S abs
pacman -S base-devel

Führt man danach als Benutzer root abs in einem Terminal aus, wird das Verzeichnis /var/abs mit den PKGBUILDs der verschiedenen Repos core, extra und community gefüllt. Die PKGBUILDs der Software befinden sich im namensgleichen Verzeichnis, welches nur noch auf den Rechner mit ConnochaetOS kopiert werden muss oder auch gleich an Ort und Stelle benutzt werden kann.

In meinem Fall wollte ich drei meiner Favoriten mtPaint, Irssi und C* Music Player für die i586 Architektur und ConnochaetOS übersetzen. Dazu genügt es, das sogenannte ARCH-Feld um den Eintrag ‚i586‘ zu erweitern.

Für Irssi war das schon der einzige Trick. Mit

makepkg -s

im Verzeichnis, wo auch das PKGBUILD liegt, konnte ich dann das Paket kompilieren und mit

pacman -U Name_des_Pakets.tar.xz

installieren.

Beim C* Music Player alias cmus brauchte ich hingegen noch die Bibliothek libao und musste libpulse und libmpg als Abhängigkeiten streichen. Auf dem Thinkpad 600 benutze ich sowieso ausschließlich ALSA.

Für mtPaint wurde noch die Bibliothek lcms2 benötigt, die ich zum erfolgreichen Kompilieren zuerst übersetzen und installieren musste. Kurz zusammengefasst muss man also lediglich Pakete für i586 kompilieren und ggf. Abhängigkeiten entfernen, die man sowieso nicht gebrauchen kann. Zum Schluss kann man dann jedes beliebige Programm auch mit ConnochaetOS benutzen. Einziger Nachteil: Man muss sich in Zukunft um die Updates selbst kümmern.

Ihr könnt alle PKGBUILDs und auch noch ein paar zusätzliche von KMandla mit Hilfe des folgenden Links herunterladen.

ConnochaetOS_PKGBUILDs.tar

Hier ist noch ein PKGBUILD-Beispiel mit Irssi:

# $Id: PKGBUILD 125226 2011-05-25 19:11:10Z foutrelis $
# Maintainer: Giovanni Scafora <giovanni@archlinux.org>
# Contributor: Dan McGee <dan@archlinux.org>

pkgname=irssi
pkgver=0.8.15
pkgrel=5
pkgdesc="Modular text mode IRC client with Perl scripting"
arch=('i586')
url="http://irssi.org/"
license=('GPL')
depends=('glib2' 'openssl' 'perl')
optdepends=('perl-libwww: for the scriptassist script')
backup=(etc/irssi.conf)
source=(http://irssi.org/files/${pkgname}-${pkgver}.tar.bz2)
options=('!libtool')
md5sums=('1dcb3f511b88df94b0c996f36668c7da')

build() {
  cd "${srcdir}/${pkgname}-${pkgver}"

  ./configure --prefix=/usr 
              --enable-ipv6 
	      --with-proxy 
	      --sysconfdir=/etc 
	      --with-perl-lib=vendor
  make
  make DESTDIR="${pkgdir}" install
}

Arch Linux: Paketsignaturen mit GnuPG und Pacman 4

Vor drei Tagen wurde auf archlinux.org die gute Nachricht verkündet, dass Archs neuer Paketmanager Pacman 4 nun in den „Core“-Paketquellen verfügbar ist. Ich hatte im letzten September noch laut über die Sicherheitsarchitektur der Paketverwaltung nachgedacht und damals die Diskussion zu dem Thema näher verfolgt, die schon vor Jahren angestoßen wurde aber erst durch einen kritischen lwn.net Artikel an Fahrt gewann.

Währenddessen war man nicht untätig und 893 commits von 24 Helfern später, ist es nun gelungen eine Reihe von neuen Feature zu implementieren, darunter eben auch das Signieren von Paketen mit GnuPG.

Zuerst fiel mir auf, dass ich yaourt und dessen Abhängigkeit package-query vor einem Systemupgrade entfernen musste, da package-query auf Pacman in einer Version < 3.6 angewiesen war. Danach wurde zuerst Pacman aktualisiert, bevor ich mir das neue Sicherheitskonzept näher anschauen konnte.

Als erstes sollte man den neuen GnuPG Schlüsselbund mit pacman-key --init anlegen. Zum Thema Package Signing und Pacman-Key gibt es schon einen hilfreichen Eintrag im Wiki. Ausführlich wird der gesamte Prozess auch auf Allan McRaes Homepage erläutert.

Nachdem mit pacman-key sowohl Schlüsselbund und ein Grundgerüst an Konfigurationsdateien angelegt worden ist, kann man in /etc/pacman.conf seine persönlichen Vorstellungen von Sicherheit einstellen. Zur Zeit ist das Überprüfen der Paketsignaturen nämlich noch mit der Variablen SigLevel = Never abgeschaltet.

Mit SigLevel = Optional TrustedOnly werden Pakete auf ihre Signaturen hin überpüft, jedoch muss man jedem unbekannten Schlüssel noch einzeln vertrauen. Eine typische Fehlermeldung sieht dann am Anfang so aus:

pacman -S transmission-gtk
resolving dependencies…
looking for inter-conflicts…

Targets (1): transmission-gtk-2.42-2

Total Download Size: 0.61 MiB
Total Installed Size: 2.57 MiB

Proceed with installation? [Y/n]
:: Retrieving packages from extra…
transmission-gtk-2.42-2-i686 625.7 KiB 410K/s 00:02 [########################################] 100%
(1/1) checking package integrity [########################################] 100%
error: transmission-gtk: key „E8F18BA1615137BC“ is unknown
:: Import PGP key 615137BC, „Ionut Biru „, created 2011-04-19? [Y/n] n
error: failed to commit transaction (invalid or corrupted package (PGP signature))
Errors occurred, no packages were upgraded.

Deswegen sollte man zuerst die sogenannten MasterKeys importieren. Diese fünf Hauptschlüssel werden dazu benutzt um die Schlüssel anderer ArchLinux-Entwickler zu unterschreiben. Gemäß dem Web of Trust ist das marginale Vertrauen in drei dieser Schlüssel ausreichend, um einen anderen mit ihnen unterschriebenen Schlüssel als gültig anzusehen. Selbst im schlimmsten Fall, wenn zwei der MasterKeys widerrufen werden müssten, wäre also das Sicherheitskonzept weiter in Takt.

Problematisch ist momentan die Verteilung dieser Schlüssel. Es gibt z.B. noch kein pacman-keyring Paket, mit welchem alle GnuPG-Schlüssel automatisch und benutzerfreundlich eingerichtet werden können. Außerdem haben noch nicht alle ArchLinux-Entwickler ihre GnuPG-Schlüssel unterschreiben lassen, weswegen es zu Warnmeldungen kommt. Dies ist auch der ausschlaggebende Grund, warum Arch Linux mit Pacman 4 standardmäßig noch auf die Validierung verzichtet.

Eine einfache Möglichkeit die fünf MasterKeys zu importieren, ist diese For-Schleife zu benutzen.

for key in FFF979E7 CDFD6BB0 4C7EA887 6AC6A4C2 824B18E8; do
pacman-key --recv-keys $key
pacman-key --lsign-key $key
printf 'trustn3nquitn' | gpg --homedir /etc/pacman.d/gnupg/ 
--no-permission-warning --command-fd 0 --edit-key $key
done

Halten wir mal fest, dass Arch Linux einen großen Schritt in Sachen Paketsicherheit nach vorne gemacht hat. Es braucht aber noch den letzten Feinschliff in den kommenden Wochen, um das Vertrauen in das neue System auch tatsächlich herzustellen.