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?

Den Terminalmultiplexer GNU Screen im Solarized-Thema erstrahlen lassen

Hier ist eine kleine Notiz, wie man ganz einfach Anwendungen und die Shell in GNU Screen mit dem fantastischen Solarized-Thema aufpolieren kann. Die Lösung war schließlich ganz einfach, auch wenn ich zuerst gedacht hatte, es würde länger dauern das Problem zu lösen.
Bisher sahen Verzeichnisse und Dateien in Screen trotz meiner Umstellung auf "Solarized" grau in grau aus.
rxvt-unicode ohne solarized
 
Ich fand schnell heraus, dass Screen einen eigenen Wert "screen" für die $TERM-Variable hatte, der sich von meinem favorisierten Terminalemulator "rxvt-unicode-256color" unterschied. In der ~/.screenrc lässt sich der Wert in der Theorie mit

term     rxvt-unicode-256color

ändern. Bei mir passierte jedoch nichts. Also warum nicht den Zustand akzeptieren und meine ZSH-Einstellungen in ~/.zshrc.local erweitern.

ZSH

if [ $TERM = rxvt-unicode-256color ] || [ $TERM = screen ]; then
        eval `dircolors $HOME/.dir_colors`
fi

Am Ende musste lediglich die if-Abfrage so erweitert werden, dass nicht nur in Rxvt-unicode-256color, sondern auch in Screen die Farbpalette Solarized geladen wurde.
 
rxvt-unicode mit solarized

Vim

Blieb nur noch Vim übrig. Hier ist die Syntax geringfügig anders. Um tatsächlich 256 Farben zu erhalten, muss t_Co auf 256 gesetzt werden, der Rest ist wieder nur eine Erweiterung der IF-Abfrage.

set t_Co=256
set background=dark
if (&term=="rxvt-unicode-256color" || &term=="screen")
        colorscheme solarized
endif

Danach erstrahlt sowohl der normale Terminalemulator als auch Screen in Solarized. Trivial. 🙂

SSH: Deaktivieren von StrictHostKeyChecking

Auf meinem Intel-Core-Duo-Rechner benutze ich verschiedene Betriebssysteme und betreibe ein Multiboot-System. Das hilft mir dabei Aufgaben und Software zu trennen, die ich nicht alle gemeinsam unter einem System installieren möchte.
Regelmäßig kommt es jedoch vor, dass ich mich per SSH von einem Laptop zu diesem Rechner verbinde oder Daten per scp austausche. Als vertrauenswürdiges Ziel habe ich dabei meine Debian-Testing-Installation mit Gnome 3 ausgewählt und den dortigen Host-Key zu meiner Datei ~/.ssh/known_hosts hinzugefügt.
Wechsele ich dann zu einem parallel installierten Betriebssystem, begrüßt mich diese Meldung hier.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!

Der SSH-Klient macht hier alles richtig und warnt mich davor, dass die Identifikation des Rechners sich nun geändert hat. Das hat mich bisher nie richtig gestört. Entweder habe ich die Datei .ssh/known_hosts gelöscht oder mich von einem anderen Laptop eingeloggt, der diese Installation als vertrauenswürdig eingestuft hat.
Man kann aber auch das sogenannte StrictHostKeyChecking deaktivieren, indem man sich eine entsprechende Konfiguration in ~/.ssh/config anlegt. Prinzipiell würde ich nie auf die Idee kommen dieses Sicherheitsfeature auszuhebeln, insbesondere dann nicht, wenn ich mich im Internet zu einem entfernten Rechner verbinde. Mein Laptop und der Core Duo stehen jedoch nur wenige Meter auseinander und werden dazu oft noch per Kabel verbunden. Von daher ist das Risiko eines Man-in-the-Middle-Angriffs überschaubar.

Meine Lösung sieht nun so aus:
Ich habe die Datei ~/.ssh/config mit folgendem Inhalt angelegt.

Host loki
         StrictHostKeyChecking no
         UserKnownHostFile /dev/null

Wenn ich nun ssh loki eingebe, wird SSH diesen speziellen Host weniger streng prüfen und ich kann mich problemlos zum selben Rechner verbinden, selbst wenn sich das Betriebssystem geändert hat.
Anstatt loki lässt sich auch 192.168.1.207 schreiben und mit der Wildcard * sogar jeder Rechner von der strengen Überprüfung ausnehmen, was ich aber nicht empfehlen kann.
Eine weitere Möglichkeit bietet der Alias-Befehl.  z.B.

alias insecssh='ssh -o "StrictHostKeyChecking=no" -o "UserKnownHostsFile=/dev/null"


Mit insecssh loki könnte man sich danach auch ohne Anlegen einer config-Datei zum entfernten Rechner verbinden.
Für die eigenen vier Wände ist das erst einmal ausreichend. 😉
Changelog:
01.09.2012 Alias insecssh der GRML-Konfiguration hinzugefügt.

snapshot.debian.org: Eine Zeitreise in die Vergangenheit des Debian-Archivs

Während meiner Experimente mit Debian Unstable, den Nvidia-Treibern und meinem Spielesystem habe ich als weitere Möglichkeit, neben Backports oder Upgrades auf experimentelle Pakete, einen sehr nützlichen Dienst von Debian in Anspruch genommen.

snapshot.debian.org

Dieser Service startete am 12. April 2010 und stellt eine Art Zeitmaschine dar, die es möglich macht alle Pakete seit 2005, die schon lange aus den aktuellen Repositorien verschwunden sind, erneut installieren zu können.
Am Beispiel des Grafikkartentreibers von Nvidia will ich kurz erklären, wie er funktioniert.

Paketsuche

Wenn ihr auf snapshot.debian.org steuert, lässt sich in der linken Navigationsspalte nach Quell- oder Binärpaketen suchen, die alle über den verlinkten Anfangsbuchstaben zu erreichen sind. In meinem Fall wollte ich eine ältere Version des Nvidia-Treibers ausprobieren, die weder in Wheezy noch in den Backports verfügbar war.
Nachdem man Kategorie n ausgewählt hat, befindet man sich auf einer Übersichtsseite aller Pakete mit Anfangsbuchstaben n. Aus dem Quellpaket nvidia-graphics-drivers werden die verschiedenen Binärpakete für Debian gebaut. Interessiert ihr euch für 275.36 seid ihr nur einen Klick vom Download der Quellen und der Binärpakete dieser speziellen Version entfernt.
Natürlich gibt es auch ein Suchfeld auf der Hauptseite, das die Suche etwas abkürzt, sofern man den exakten Namen des Pakets kennt.

Snapshot-Archiv in sources.list einbinden

Am interessantesten ist aber die Möglichkeit einen Snapshot des Archivs in die sources.list einzubinden und dann wie gewohnt mit apt-get oder aptitude Pakete zu installieren.
Neben den archivierten Paketen wird immer auch ein Link angeboten, der so aufgebaut ist, dass er anzeigt aus welchem ehemaligen Repo das Paket stammt (also z.B. Security, Backports, main, non-free, usw.) und sich dann in die sources.list mit dem vorangestellten deb einfügen lässt.

deb http://snapshot.debian.org/archive/debian/20111105T032915Z/ wheezy main contrib non-free

Der Snapshot stammt bei dem oben genannten Beispiel aus dem Jahr 2011 und wurde am 05.11. um 03.29 Uhr und 15 Sekunden Zulu-Zeit (UTC) archiviert. Wenn man nun die normale deb-Zeile deaktiviert hat, diese hier freischaltet und ein aptitude update macht, erscheint jene Fehlermeldung.

E: Release file for http://snapshot.debian.org/archive/debian/20111105T032915Z/dists/wheezy/InRelease is expired (invalid since 261d 16h 13min 14s). Updates for this repository will not be applied.

Hier wird signalisiert, dass die Pakete veraltet sind, weswegen Apt ein Update des Paketcaches verhindern will. Damit es trotzdem funktioniert, lässt sich Apt folgendermaßen belehren.
aptitude -o Acquire::Check-Valid-Until=false update
Danach lassen sich die älteren Pakete wie gewohnt installieren.

archive.debian.org

Noch ein kleiner Tipp. Wer auf der Suche nach der ganz alten Debian-Veröffentlichung ist, sollte archive.debian.org einen Besuch abstatten.

Nvidia-Treiber und das Spielesystem: Zurück zu Debian Stable

In den vergangenen Monaten habe ich einige leidvolle Erfahrungen mit dem Nvidia-Treiber gemacht und dieses schlimme Unbill unter dem Schlagwort Nvidia in diesem Blog kundgetan. Nun mischten sich unter den Ärger mit den proprietären Grafikkartentreibern anderweitige Hardwareprobleme mit meinem Mainboard und es war nicht immer einfach das auseinanderzuhalten. Zu Nvidias Ehrenrettung muss ich noch hinzufügen, dass es für einen Grafikkartenhersteller auch nicht immer ganz einfach ist, das gesamte Sortiment an Modellen fortwährend mit aktuellen Linuxtreibern zu versorgen, wenn die ABI des X-Servers scheinbar monatlich wechselt. Das mag aber auch meine laienhafte Sicht der Dinge sein und am Ende hat immer derjenige die Torte im Gesicht, der unfreie Treiber anbietet und den Quellcode unter Verschluss hält oder?
Tatsache ist, dass ich seit der Version 1.10 des X-Servers und dem Nvidia-Treiber 275.36 kein vernünftiges X plus Treiberpaar mehr auf meinem Rechner benutzen konnte. Alles was danach kam war schlicht unbrauchbar. In meinem /var/log/Xorg.0.log war dann z.B.

Increasing EQ size to 512 to prevent dropped events

oder

EQ overflow continuing. 100 events have been dropped

zu lesen. Aktuell hängt bei mir jedes Mal das gesamte System, wenn ich z.B den Webbrowser oder ein Spiel wie OpenArena schließe. Wenn ich Glück habe hört es irgendwann von alleine auf, wenn ich Pech habe friert der Computer ein. Keine wirklich guten Voraussetzungen für eine dauerhafte Beziehung, weswegen ich auf einem zuerst reinen Debian Sid mittlerweile den alten X-Server und Nvidia-Treiber aus den Backports von Squeeze beziehe und auf Hold gesetzt habe.
Nicht wirklich überraschend holte mich der gleiche Fluch auch mit Ubuntu 12.04 ein. Meine kleine Sammlung von Tipps zum Lösen der Nvidia-Probleme ist, man glaubt es kaum, seit der Veröffentlichung einer der meistgelesenen Artikel dieses Blogs. Ich denke, es klingt zu Unrecht etwas gehässig, aber ich bin froh, dass ich da draußen nicht alleine mit meinem Nvidia-Ärger bin. 😛
Nach wie vor halte ich es so, dass ich zuerst die freien Nouveau-Treiber installiere. Auf den älteren Laptops sind natürlich noch ganz andere Grafikkarten verbaut (Stichwort Neomagic). Überall dort wo ich ein paar Mails abrufe, im Netz surfe oder einen Film anschaue, reicht das aber ohne Probleme aus.

Das Spielesystem

Gleiches kann ich von einem Spielesystem nicht mehr behaupten. Hier ist 3D-Performance schlicht ein Muss. Um jeden Fehler meinerseits auszuschließen, habe ich nochmal versucht ein sauberes Wheezy mit allen momentan zur Verfügung stehenden Treibern zum Laufen zu bringen. Leider Fehlanzeige. Sowohl 295 aus den Backports, 302 in Wheezy oder sogar der brandneue 304 aus Experimental, immer das gleiche niederschmetternde Ergebnis. Und dabei sollte doch schon mit Version 295.59 meine 9600GT wieder zu den Gewinnern zählen.
Man sieht daran aber auch, es liegt nicht an Debian Sid. Als ich vor einem Jahr das Multiboot-System aufgesetzt habe, wollte ich auch herausfinden wie sinnvoll ein solches System für Spieler ist. Heute bin ich mir sicher: Ja, man kann Debian Unstable benutzen, aber was nützt die marginale Performance-Verbesserung des Treibers, wenn er nicht funktioniert?
Ich habe ein altes Backup eingespielt und in der sources.list die Quellen von Sid auf Wheezy geändert. Da ich außer den Spielen und dem Grafikkartentreiber keine neuere Version der Software vermisst und ich diese Versionen fast ausschließlich auch über die Backports bekommen hätte, bleibt als Fazit nur zu sagen:
Zurück zu Debian Stable

Jessie ist der neue Codename für Debian 8.0

Vor wenigen Stunden hat Adam D. Barrat auf der Mailingliste debian-devel-announce diese Ankündigung öffentlich gemacht.
Wie viele sicher wissen besteht in Debian die Tradition, die Codenamen für die nächste stabile Veröffentlichung von Charakteren aus dem Film "Toy Story" abzuleiten.
Das hier ist Jessie.
Jessie aus dem Film Toy Story
Neben Bo ist sie der zweite weibliche Charakter, der aus dem Film als Codename für Debian verwendet wird. In Wikipedia wird sie als mutig, athletisch aber auch leicht reizbar beschrieben. Wie der Name für Debian 9.0 heißen könnte, lässt sich durch ein Lesen dieser Liste erfahren.
Ich bin schon jetzt gespannt, welche Ziele sich Debian für die übernächste Veröffentlichung der Distribution setzen wird. Doch bevor es soweit ist, müssen noch für Wheezy eine ganze Menge Bugs gefixt werden. Da ich mich persönlich mehr und mehr für die Entwicklung von Debian interessiere, sind hier mal ein paar Links wie und wo man helfen kann, damit Wheezy so schnell wie möglich veröffentlicht werden kann.

Gegen die Feuerwand: Mal wieder DRDoS-Attacke auf OpenArena-Server

Seit ein paar Tagen wird mein OpenArena-Server erneut mit einer sogenannten DRDoS-Attacke überzogen. Der oder die Angreifer senden dabei gefälschte IP-Pakete mit Hilfe von Spoofing an den Server, damit dieser wiederum Statusanfragen an Webserver und ähnliche Dienste weiterleitet, deren Kapazitäten irgendwann nicht mehr ausreichen, um die gerechtfertigten Anfragen zu beantworten.
Mit iftop sieht das im Moment so aus:

Ich bin mir nicht sicher, ob das Ganze überhaupt durchdacht worden ist, momentan rauscht einfach alles in die Firewall. Es wird nicht einmal geprüft, ob der Server verwundbar ist, sondern einfach stur immer die gleichen Anfragen geschickt. Dass die Attacke somit sehr ineffizient ist, scheint niemanden zu stören.
Ich bin mit dem Server einen Port weitergezogen, um irgendeine negative Auswirkung auf das Spielerlebnis auszuschließen. Die beim letzten Mal erstellten Firewallregeln und der gepatchte Server haben zuvor ihr Übriges getan.
Da zwar sehr viele Anfragen hereinkommen, jedoch keine beantwortet wird, kann man diesen Umstand wunderbar mit vnstat beobachten. Normalerweise ist der Wert des TX-Graphen (grau) größer als der RX-Graph (grün).
Vnstat-stündlicher-Netzwerkverkehr
Vnstat-täglicher-Netzwerkverkehr
Letztes Mal hat es knapp zwei Wochen gedauert bis der Spuk vorbei war. Mal schaun wie lange es dieses Mal dauert.

Upgrade auf Debian Wheezy: Toshiba Portégé 3110CT Pentium II 300 MHz mit 64 MB RAM

Zur Zeit verwende ich einen meiner ältesten Laptops, den Toshiba Portégé 3110CT zum Debuggen des OpenArena-Servers. Ich war es leid die ganzen Tests auf meinem Live-Server durchzuführen. Während ich die aktuelle Testing-Version 0.8.8-5 von OpenArena einspielte, kam mir die Idee gleich das ganze System auf Wheezy upzugraden.
Nach wie vor war auf dem Laptop aus dem Jahr 1999 Debian Squeeze in Betrieb gewesen, welches ich im Jahr 2010 zusammen mit Fluxbox und mit Hilfe von CD-ROM und PEX installiert hatte. Zusammen mit den üblichen Verdächtigen, Software ohne und mit X, verrichtete er bisher auch klaglos seine Arbeit. Ich benutze ihn immer noch hauptsächlich als Heimserver, da man ihm hier seine 64 MB Arbeitsspeicher selten anmerkt.

Eine Weile hatte ich auch überlegt Squeeze gegen ein anderes Betriebssystem wie Slitaz oder gar CRUX auszutauschen, die Überlegung jedoch schnell wieder verworfen, da es schlicht funktionierte. Ja, man darf Distro-Hopping auch mal widerstehen. 🙂
Zusätzlich ist es in den letzten zwei Jahren schwieriger geworden ein neues Betriebssystem via CD-ROM-Laufwerk zu installieren. Ich bin mir nicht sicher, ob man das früher bei vergleichbaren Subnotebooks von Toshiba jedes Mal machen musste, bei meinem durfte ich zumindest immer eine Tastenkombination (ich glaube es war CTRL+c) beim Starten drücken, damit vom CD-ROM-Laufwerk gelesen und gebootet werden konnte. Das scheint nun alles hinfällig zu sein, das CD-ROM-Laufwerk möchte nicht mehr und großen Bedarf für eine PEX-Installation habe ich auch nicht.
Wozu also in die Ferne schweifen, wenn ich Debian Squeeze durch ein Dist-Upgrade in Debian Wheezy verwandeln konnte? Nachdem ich die Quellen auf Wheezy umgeändert hatte, installierte ich zuerst apt und aptitude aus dem Wheezy-Repo. Prinzipiell, aber gerade auch wegen Multiarch, macht es Sinn hier zuerst gezielt ein Upgrade zu machen, damit der Paketmanager später alle Konflikte sauber auflösen kann. Dann folgte nur noch

aptitude full-upgrade


Das Problem bei jedem Dist-Upgrade scheint zu sein, dass neue Pakete installiert werden sollen, die man nicht unbedingt haben wollte. Nach dem Upgrade hatte ich unter anderem PolicyKit, ConsoleKit, ein paar Gnome3-Werkzeuge und -Bibliotheken zusätzlich installiert, die ich nicht gebrauchen konnte. Dieses Dilemma lässt sich umgehen, indem gezielt einzelne Pakete erneuert werden oder man entfernt schon vorher überflüssige Pakete, die neue Abhängigkeiten in das System einfließen lassen.
Man kann natürlich auch später Debian erneut auf minimal stutzen und den Aufräumtipps folgen und schon ist das System wieder in dem gewohnt schlanken Zustand. Mir hat sowohl Deborphan als auch Debfoster wieder einmal geholfen.
Weitere Überraschungen gab es danach keine mehr, weshalb ich mich nun einfach über weitere zwei Jahre mit Debian auf dem Toshiba freue und alle Finger kreuze, dass die Hardware weiterhin intakt bleibt. 🙂

Hier sieht man die aktuelle RAM-Auslastung und die Last auf dem Server. Ich vermute gdb ist daran Schuld, dass letztere um die 1.0 pendelt. Im Spiel selbst merkt man nichts davon.
Htop-Anzeige von Speedy
Der OpenArena-Server funktioniert in der Tat ziemlich gut auf dem Rechner. "Leider" muss ich dazusagen, denn ich möchte ja, dass er abstürzt und die Ergebnisse auf dem Live-System bestätigt. 🙂
Bisher verfolge ich zwei Bugs #664637 und #681812. Letzterer lässt sich zu 100% reproduzieren, einen Backtrace mit dem GNU Debugger habe ich auch schon erstellt. Der erste Bug ist z.Z das Problem, da er mit der aktuellen OpenArena-Version nur noch sehr selten auftritt und er sich nicht gezielt auslösen lässt.
Ich verzichte an dieser Stelle auf einen Bericht meiner zahllosen gescheiterten Versuch einen Core-Dump des Servers zu erstellen. Erst nachdem ich ihn lokal getestet habe und er mit Root-Rechten läuft (böse, ich weiß), konnte ich für #681812 innerhalb von gdb mit dem Befehl generate-core-file diese Datei erzeugen, die immerhin 165 MB groß ist. Weitere Details spare ich mir, weil ich selbst noch dabei bin mich mit der Materie vertraut zu machen und Debuggen nun wirklich nicht den gleichen Spannungsfaktor wie ein guter Krimi hat. Sagte Nuff.

Debians offizielle Multimedia-Pakete kontra deb-multimedia.org

Erst kürzlich ist mir aufgefallen, dass ein Namenswechsel stattgefunden und debian-multimedia.org sich in deb-multimedia.org umbenannt hat. Christian Marillat, langjähriger Debianentwickler und Verantwortlicher dieses inoffiziellen Debian-Repos für Multimedia-Software, tat dies aber nicht freiwillig. Am 5. Mai 2012 wurde Christian von Stefano Zacchiroli, seines Zeichens zum dritten Mal wiedergewählter Anführer des Debianprojekts, aufgefordert auf die Differenzen zwischen ihm und dem Debian-Multimedia-Team einzugehen oder sich ausdrücklich von dem Namen Debian in seinem Webauftritt zu distanzieren.
Er zog Letzteres vor und benannte die bekannte Domain debian-multimedia.org in deb-multimedia.org um. Zur Zeit gibt es noch eine Umleitung und auch die alten Einträge in der sources.list funktionieren noch. Das wird sich in ein paar Monaten aber ändern.

Die Geschichte

Was war passiert? Nun zum einen achtet Debian seit einiger Zeit verstärkt darauf, dass Domains, die in ihrer Bezeichnung den Namen Debian tragen, von offiziellen Debianentwicklern geführt werden, weswegen meine Anfrage für debiangames.de auch zum Scheitern verurteilt war. Nun war mir von vorne herein bewusst, dass meine Chancen schlecht standen, debian-multimedia.org gab es aber schon seit zehn Jahren und so ziemlich jeder, der mit Debian in Berührung kommt, stößt irgendwann auf Christian Marillats inoffizielles Multimedia-Archiv.
Das Problem lässt sich leicht erklären. Die Chemie stimmt zwischen dem offiziellen Multimedia-Team und Christian Marillat nicht mehr. Nachzulesen unter anderem in der FAQ von Debian-Multimedia oder diesem Beitrag auf der Mailingliste der Debian-Entwickler, dessen Betreff, "debian-multimedia.org considered harmful", für sich spricht. Die Zusammenarbeit, wenn man davon überhaupt sprechen kann, ist so zerrüttet, dass keine Absprachen zwischen dem offiziellen Team und Christian Marillat mehr stattfinden.
Durch die eigenwillige Benennung seiner Debianpakete werden diese selbst dann installiert, wenn sie in Debian in einer neueren Version vorliegen sollten. Durch das Mischen unterschiedlicher Versionen kommt es jedoch bei manchen Nutzern zu Bugs und Abstürzen. Da manche debian-multimedia.org für eine offizielle Debian-Domain gehalten haben, wurden Fehlerberichte eben auch für Debian verfasst, womit die Paketverwalter aber nichts anfangen konnten und genervt die Fehlerberichte wieder geschlossen haben. Der Konflikt war also vorprogrammiert.
Debian-Multimedia.org ist deswegen so bekannt, weil es seit zehn Jahren die wohl einzige externe Quelle war, wo man problematische Multimedia-Software für Debian ohne Umstände herunterladen konnte. Wobei "problematisch" mit Patenten behaftet und nicht DFSG-konform bedeutet. Hier konnte man schon sehr früh die Software finden, mit der es möglich ist DVDs auf dem heimischen PC abzuspielen oder erste Debianpakete von Mplayer bewundern.
Die Multimedia-Situation hat sich nach und nach in Debian gebessert. Zum einen hat das Multimedia-Team gute Arbeit geleistet und wichtige Codecs und Software DFSG-konform nach Debian bringen können. Dazu musste die Software oft aufwendig analysiert und unfreie Komponenten entfernt werden. Natürlich kostet das mehr Zeit als einfach alles so zu belassen und dem Nutzer ein unfreies Paket vorzusetzen.
Zum Anderen gab es letztes Jahr einen Lichtblick in der Patenthölle. Zusammen mit Rechtsanwälten des Software Freedom Law Center und dem Debian-Projekt wurde eine FAQ zum Thema Patentrichtlinie erstellt. Hierin werden Entwicklern von Freier Software Wege und Verhaltensweisen aufgezeigt, um sich im Einklang mit bestehendem Recht zu bewegen.
Dabei wurde deutlich, dass es durchaus rechtmäßig sein kann patentbehaftete Software in einer Distribution wie Debian zu vertreiben, wenn man gewisse Punkte beachtet. Interessanterweise scheint es (in den USA) umso unwahrscheinlicher zu sein, wegen willentlicher Patentrechtsverletzung angeklagt zu werden, je weniger man von dem eigentlichen Patent weiß und je geringer der kommerzielle Nutzen ist, den man aus dem Patent für sich selbst zieht. Wer jetzt die Augenbraue hebt, sollte sich den ganzen Text mal selbst durchlesen. 🙂
Das eröffnet Problempaketen wie Avidemux die Chance, das übrigens seit neun Jahren auf die Aufnahme in Debian wartet, tatsächlich in Debian zu erscheinen. Es sei denn natürlich die technischen Probleme lassen sich lösen...Ein interessanter Fehlerbericht mit Sprüngen von teilweise 2 Jahren zwischen einzelnen Posts. 😉
Doch genau solche Pakete wie Avidemux gibt es eben schon seit einer Ewigkeit bei deb-multimedia.org. Ein Grund warum Linux Mint Debian diese externe Quelle standardmäßig freischaltet und mit verbesserten Multimediafähigkeiten wirbt, dabei aber unter den Teppich kehrt, dass Softwarefreiheit nicht ganz so ernst genommen wird.

Die Alternativen

  1. Probiert immer zuerst die Multimedia-Software in Debian selbst aus. In den meisten Fällen ist die offizielle Software nämlich ausreichend, um Videos und Musik anschauen und hören zu können.
  2. Treten tatsächlich einmal Probleme mit dem Abspielen auf und weder Totem mit Gstreamer, Mplayer oder VLC können weiterhelfen, dann greift auf die Backports zurück. Denn wahrscheinlich benutzt ihr Debian Stable und benötigt lediglich eine neuere Version eurer Software.
  3. Wenn alles versagt und sozusagen als letztes Mittel: Schaltet deb-multimedia.org frei und installiert euch die w32codecs, libdvdcss2 und Avidemux, wenn ihr sie denn tatsächlich brauchen solltet. Ich hatte persönlich noch nie größere Probleme mit Christian Marillats Software. Ich gebe aber zu, dass ich ziemlich enttäuscht bin, wie er auf die öffentliche Aufforderung von Stefano Zacchiroli reagiert hat.

Apt-Pinning

Um mehr Kontrolle über Drittquellen wie deb-multimedia.org zu haben, könnt ihr diesen Paketen eine niedrige Pin-Priorität zuweisen und mit Apt-Pinning arbeiten. Ersetzt einfach "testing" mit eurem bevorzugten Debian-Repo. Die Datei /etc/apt/preferences sieht z.B. so aus.

Package: *
Pin: release o=Debian, a=testing
Pin-Priority: 990
Package: *
Pin: origin www.deb-multimedia.org
Pin-Priority: 101

Zusätzlich muss noch diese Zeile in /etc/apt/sources.list nachgetragen werden.

deb http://www.deb-multimedia.org testing main non-free

Jetzt solltet ihr aber keine Fehlerberichte mehr an den Bugtracker von Debian schicken. 😈

Fwlogwatch: Ein Firewall-Loganalysierer und Sicherheitswerkzeug

Eine der ersten Amtshandlungen auf dem neuen vServer war es, eine Firewall aufzusetzen. Das stellte sich Dank ufw als gar nicht so schwierig heraus. Ich experimentierte dann mit verschiedenen Logleveln und stellte schnell fest, dass ich ohne einen Loganalysierer für die Firewall schnell den Überblick verlieren würde.
Ich installierte daraufhin Fwlogwatch, ein Sicherheitswerkzeug, dass schon seit einem Jahrzehnt als Freie Software vorliegt. An dieser Stelle wollte ich es kurz vorstellen, da ich nicht wirklich viele Erfahrungsberichte dazu gefunden habe, die sich mit Fwlogwatch auseinander gesetzt haben. Mit Sicherheit gibt es noch andere Loganalysierer für Firewalls. Welche kennt und benutzt ihr davon und wie geht ihr generell mit dieser Thematik um?

Installation und Konfiguration

aptitude install fwlogwatch


Fwlogwatch kann sowohl per Konfigurationsdatei als auch über die Kommandozeile konfiguriert werden. Nur die Optionen, die nicht ausdrücklich in fwlogwatch.config definiert wurden, können per Kommandozeilenparameter geändert werden. Im Folgenden konzentriere ich mich auf die Beschreibung der Konfigurationsdatei.
Bei Debian und Ubuntu ist es am sinnvollsten zuerst die Standardeinstellungen mit

dpkg-reconfigure fwlogwatch


festzuschreiben. Die Einstellungen befinden sich danach in /etc/default/fwlogwatch. Die Screenshots zeigen die sechs Möglichkeiten, die zur Auswahl stehen. Ich habe mich dafür entschieden Fwlogwatch als Daemon im Echtzeitmodus zu starten und zusätzlich einmal täglich eine E-Mail-Benachrichtigung mit der Auswertung der vergangenen 24 Stunden zu erhalten. Auf das automatische Anlegen von Firewall-Regeln habe ich verzichtet.

Die zentrale Konfigurationsdatei existiert in /etc/fwlogwatch/fwlogwatch.config. Die Datei ist sehr gut in Englisch dokumentiert. Hier ist ein Auszug mit den für mich wichtigsten Einstellungen.

# Input-Datei
input = /var/log/messages
# Wir analysieren eine Netfilter-Firewall
parser = n
# Angezeigt werden: Quell-IP, Protokoll und Zielport.
src_ip = on
protocol = on
dst_port = on
# Diese Quelle soll ausgeschlossen werden
exclude_src_host = 123.123.123.123
# Sortierungsreihenfolge
sort_order = Sacd
# Anzeige der Paketgröße
data_amount = yes
# nur die letzten 24 Stunden anzeigen
recent = 24h
# Fwlogwatch soll als Benutzer nobody laufen
run_as = nobody
# Im Echtzeitmodus soll benachrichtigt werden
notify = yes

Einmal am Tag erhält man danach eine E-Mail, die alle Vorkommnisse in der vorher festgelegten Sortierreihenfolge auflistet. Dieser ältere Artikel für die Slackware-Distribution erklärt anhand einiger Beispiele wie man Fwlogwatch von der Kommandozeile bedient und verschiedene Sortierverfahren nutzen kann, um Muster in einem Angriff zu erkennen.

Jul 18 06:58:29 to - - [9948935.724847] [UFW BLOCK]  1 tcp packet (44 bytes) from xxx.xxx.xxx.xxx port 22
Jul 18 07:05:27 to - - [9949353.404245] [UFW BLOCK]  1 tcp packet (48 bytes) from xxx.xxx.xxx.xxx port 5900
Jul 18 07:30:49 to - - [9950876.155902] [UFW BLOCK]  1 udp packet (23 bytes) from xxx.xxx.xxx.xxx port 27970

Echtzeitmodus

Für den Echtzeitmodus existiert noch ein zusätzliches Webinterface, welches ebenfalls in fwlogwatch.config aktiviert wird. Das Statuspasswort muss verschlüsselt sein und lässt sich mit htpasswd -nb admin meingeheimesPasswort erzeugen. Man kann sich dann z.B. über einen SSH-Tunnel mit dem Webinterface verbinden.
ssh -p 44444 -L 8888:127.0.0.1:888 meinserver

server_status = yes
listen_port = 888
status_user = admin
status_password = Xjswdw/we3 #Beispiel für ein verschlüsseltes Passwort

Fwlogwatch-Status

Zum Schluss

Fwlogwatch bietet in /usr/share/doc/examples/ noch zwei CGI-Skripte, mit denen eine Zusammenfassung im HTML-Format auf einem Webserver präsentiert werden kann. Auch lassen sich alle täglichen Berichte per HTML-Mail verschicken, wenn man das möchte. Wurde notify=yes in der Konfigurationsdatei gesetzt wird zusätzlich eine Alarmnachricht versandt, wenn ein Schwellenwert an Verbindungen pro Zeitintervall überschritten wurde. Der Inhalt der Mail orientiert sich an den Angaben in /etc/fwlogwatch/fwlw_notify. Außerdem lassen sich auch automatisch neue Firewall-Regeln anlegen, wozu das Skript /etc/fwlogwatch/fwlw_respond berücksichtigt wird und externe CERT-Stellen mit vorgefertigten Templates alarmieren.
Ich persönlich finde die vielfältigen Sortierungsmöglichkeiten von Fwlogwatch nützlich, womit sich tatsächlich überhaupt erst eine Übersicht in die Analyse der Firewall-Logdateien bringen lässt. Ich stelle mir nur hin- und wieder die Frage, wie ich am besten auf die Tatsache reagiere, dass mein Server permanent gescant wird.