256bit.org Blog

Man kippe das in .xinitrc bzw. .xsession und je nachdem wieviele der angegebenen Windowmanager installiert sind, wird einer davon zufällig gestartet.

SSH Schlüssel sind erstellt und Putty wurde konfiguriert. Ein Nachteil der bisherigen Lösung ist, dass für jede Shell ein neuer ssh-agent gestartet werden muß. D.h. es kann sein, dass mehr ssh-agent laufen, als unbedingt nötig, weil man sich z.B. auf mehreren Konsolen eingeloggt hat. Das Problem hierbei ist, dass die Shells nicht ihre Umgebung voneinander erben, sondern jedesmal mit einer neuen Umgebung initialisiert werden und demzufolge einen eigenen ssh-agent starten.

Das ist nicht nur eine Verschwendung von Ressourcen, sondern auch für den Benutzer unbequem, weil er doch wieder x-mal sein Passwort eingeben muß.

Hier kommt nun keychain ins Spiel. Dabei handelt es sich um ein Wrapper - Shellscript, dass die Umgebungsvariablen vom ssh-agent persistent speichert und so auch neuen Login-Shells zur Verfügung stellt. Nebenbei schreibt es diese Umgebungsvariablen automatisch für Bourne-Shell, C-Shell und neuerdings wohl auch für die Fishshell, so dass jede Shell sie entsprechend auswerten kann.

Wenn keychain gestartet wird, schaut es nach, ob die gespeicherten Variablen noch valide sind, falls nein startet es einen neuen ssh-agent, schreibt dessen Umgebungsvariablen in ein Shellscript und fügt einen neuen Schlüssel mit ssh-add hinzu. Man muß also nur dann die Passphrase für den Schlüssel eingeben, wenn dieser das erstemal entschlüsselt wird.

Darüber hinaus besitzt keychain noch einige weitere nützliche Parameter. Hier hilft die manpage weiter.

Um keychain automatisch beim Login zu starten, sollte man einen Aufruf in das Startscript der Shell schreiben. Für die bash könnte man z.B. das folgende in ~/.bash_profile schreiben:

Ein Problem gibt es noch. Was passiert, wenn X11 gestartet wird? Man kann dem ssh-add über eine Umgebungsvariable noch mitteilen, welches Programm zur Abfrage der Passphrase gestartet werden soll. So hab ich z.B. in meiner .xinitrc folgendes definiert:

Für Debian muß dafür noch das Paket ssh-askpass installiert werden und schon fragt der ssh-agent grafisch nach, was gestartet werden soll. Alternative Pakete existiern. apt-cache search ssh-askpass zeigt sie an

Mittlerweile beherrscht keychain auch den Umgang mit dem gpg-agent. Vereinfacht gesagt, ist die Funktion von gpg-agent ähnlich dem ssh-agent - es verwaltet das Passwort des geheimen gpg-Schlüssels.

Weitere Informationen zu keychain bekommt man auf der Website des Projekts. Eine genaue Vorstellung liefert eine Artikelserie auf developerworks (Teil 1, Teil 2 und Teil 3)

weitere Artikel kommen bestimmt...

Im vorigen Artikel wurde beschrieben, wie man ssh mit Schlüsseln benutzt. Man kann einen so generierten privaten Schlüssel auch mit Putty benutzen. Im Lieferumfang von putty befindet sich das Programm Putty Key Generator (puttygen.exe). Diese Programm startet man.

Dann clickt man auf Conversions, Import Key:

Und dann muß man seinen privaten Schlüssel id_rsa entschlüsseln:

Und dann speichert man diesen Schlüssel im Putty eigenen Format (putty private key):



Mit dem Programm Putty Authentication Agent (pageant.exe) kann ein so generierter Schlüssel geladen werden und steht dann putty zum Anmelden im Speicher zur Verfügung.


Mit einem kleinen Batchscript kann man beim Start von Windows dafür sorgen, dass immer pageant.exe gestartet wird:

Im Skript einfach die Pfade anpassen und in den Startup/Autostart Ordner kopieren und schon startet bei der Anmeldung von Windows ein kleines Fenster von pageant.exe und möchte gern das Passwort für den angegebenen Schlüssel haben.

Das könnte man natürlich noch ausbauen und gleich eine ssh-Verbindung zu einem Server starten.

Dies ist eine kurze Anleitung, wie man ssh mit keys benutzt. Vergleichbare Anleitungen finden sich wahrscheinlich haufenweise bei Google. Dies hier ist meine, damit ich nicht immer Google bemühen muss.

Voraussetzung dafür ist natürlich, dass PublicKey-Authentifizierung überhaupt erlaubt ist. Dies geschieht durch die Anweisung PubkeyAuthentication yes in /etc/ssh/sshd_config Und wenn man schon mal die Konfiguration prüft, kann man auch gleich überprüfen, dass Protokoll 2 verwendet wird und nicht das veraltete 1:

Sieht gut aus. Nun können wir einen Key erstellen. Dies geschieht auf dem Client, von dem nachher auf den Server zugegriffen werden soll.
Grundsätzlich gibt es 2 vershiedene Arten: DSA und RSA. Die Art des Keys wird mit dem Parameter -t angegeben(default ist hier RSA). Für RSA-keys kann mit dem Parameter -b noch die bitlänge angegeben werden (default sind hier 768bit, DSA ist nur gültig mit 1024 bit).

Wichtig: Der Key sollte immer verschlüsselt werden. Also nie eine leere Passphrase angegeben, denn falls dieser Schlüssel in falsche Hände gerät, dann hat der Angreifer damit auch gleich Zugriff auf den Server.
Der Schlüssel besteht dabei aus einem privaten und einem öffentlichen Teil. Der öffentliche Schlüssel (id_rsa.pub) authentifiziert gegen den privaten Schlüssel (id_rsa), d.h. er muß auf den Server kopiert werden. Dafür gibt es den Befehl ssh-copy-id. Man kann es aber auch händisch machen:

Fertig. Jetzt noch die Verbindung testen:

user@host ~$ ssh -v -i id_rsa user@server "exit"
[...]
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type
Enter passphrase for key 'id_rsa':
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).

Es wurde einfach eine SSH-Verbindung mit dem Schlüssel id_rsa (-i) aufgebaut, die gleich wieder beendet wurde.Die Logausgaben (-v) zeigen, dass auch wirklich die PublicKey Methode verwendet wurde (Hervorhebung durch mich).
Das Passwort wird nur zur Entschlüsselung des privaten Schlüssels (id_rsa) benötigt und nicht, um sich auf dem Server anzumelden. Es wandert also nicht über die "Leitung".

Nun ist es bisher nicht sonderlich komfortabel, die Passphrase muß auch weiterhin jedesmal eingegeben werden. Deshalb gibt es den ssh-agent. Wenn dieser gestartet wird, speichert er das Passwort im RAM und nutzt dieses dann zum einloggen. Auch diesem muß einmal das Passwort mitgegeben werden, dann jedoch benötigt er es nicht mehr, vorausgesetzt, der ssh-client weiß, dass er den ssh-agent benutzen soll.
Einen Schlüssel kann dem ssh-agent über ssh-add mitgegeben werden. Hier wird dann auch nach dem Passwort des Schlüssels gefragt.

Zunächst wird der ssh-agent gestartet:

Wenn der ssh-agent gestartet wird, startet er sofort im Hintergrund und gibt ein paar Umgebungsvariablen aus. Die Ausgabe erfolgt so, dass sie sofort an die bash weitergegeben werden kann. Damit der ssh-agent also genutzt werden kann, müssen diese Umgebungsvariablen der Shell zur Verfügung gestellt werden. Dies kann z.B. mit eval geschehen.
Neue Schlüssel können mit ssh-add hinzugefügt werden:

Damit dies z.B. automatisch bei jedem Einloggen geschieht, kann man das folgende in seine .bashrc schreiben (falls die bash die login Shell ist):

Der Nachteil, loggt man sich auf verschiedenen Terminals ein, so werden u.U. mehrere ssh-agent gestartet. Wie man das komfortabel löst, erklärt eine andere Geschichte.

Da ist es also, das neue Gimp. Die Releases Notes beschreiben die Änderungen. Neben optischen Verbesserungen (neue Icons, Verbesserungen in der Usability) gibt es auch ein Freistellungstool, Color-Management Support, Verbesserungen beim Zuschneiden, ein automatisches "Rote-Augen" - Tool und vieles weitere.

Ich bin mal gespannt, wie gut man damit dann arbeiten kann.

Ach ja, in Debian unstable ist doch tatsächlich schon gim2.4 enthalten. Nicht schlecht.

laut berichtet, es soll eine Neuauflage von Knight-Rider geben. Leider ohne David Hasselhoff.
Och wie schade! Wo er doch so viel Gutes getan hat und verantwortlich ist für die Wiedervereinigung.

Bin ich eigentlich der Einzige, der anstelle von :q q: tippt? Typischer Fall von mangelnder Koordination der beiden Hände schätze ich. Das ganze ist nervig genug, dass ich q: jetzt auf :q umgebogen habe:
:noremap q: :q
All die Jahre, die ich vim nutze, hab ich noch nie das Command-line Window (:h cmdwin) benutzt. Zur Not kann man es noch mit q/ oder q? öffnen (im normal Mode, im Command-Mode [:] durch Drücken von Ctrl-F)

Ein bißchen Spaß muß sein:
http://www.wrecker.newmail.ru/www/russia.htm
und wo wir gerade bei Spaß sind:

(via nion and xkcd)

Rein zufällig sah ich gestern die Show von Kerner, in der auch Eva Herrmann Gast war. Über diesen Skandal ist ja schon genügend berichtet worden.
Ich will auch mich zu diesem Thema eigentlich nicht weiter äußern, aber eine Sache ist mir aufgefallen.

Ziemlich zum Schluß und in einigem Durcheinander, sagte sie sinngemäß, dass in Sachsen-Anhalt die Anzahl der Kindertagesstätten ziemlich hoch sei und legte nahe, dass dies ein Grund für die geringe Gerburtenrate in Sachsen-Anhalt sei, die wohl auch im Vergleich zu anderen Bundesländern (Bayern, Baden-Württemberg) gering ist.

Ob diese beiden Fakten so stimmen, habe ich jetzt nicht überprüft. Es stimmt aber, dass wir in Sachsen-Anhalt viele Kindertagesstätten haben. Und das ist auch gut so.
Wer so eine pauschale Aussage trifft und einen direkten Zusammenhang zwischen diesen Fakten herstellt, ohne auf die Rahmenbedingungen (Arbeitslosigkeit, Verödung von Landstrichen durch Auswanderung, Infrastruktur, Sparzwang von Kommunen) hinzuweisen, gibt sich meiner Meinung nach der Lächerlichkeit preis und kann einfach nicht Ernst genommen werden.

laut schreibt, es gibt jetzt Invalidenrente für ausufernden Heavy-Metal Konsum:

Die ganzen Typen auf den Behindertenparkplätzen müssen wohl alle Heavy-Metal Invaliden sein.

Ich weiß nicht, ob es sich schon rumgesprochen hat, aber auf Youtube gibt es ein nettes Video, wie man Bilder skalieren kann, ohne wichtige Elemente zu verlieren:

Das Video ist tatsächlich sehr faszinierend.
(Wer das Englisch nicht versteht, findet hier eine kurze deutsche Beschreibung.)

Für Gimp gibt es bereits das passende Plugin (Liquid Rescale).

Mit diesem Plugin kann man das Bild skalieren (neue Größe/Breite angeben) und dabei bestimmte Bereiche explizit vor Veränderung schützen bzw. bestimmte Bereiche explizit löschen. (Man sollte vor der Anwendung einen kurzen Blick in die beiliegende Doku werfen.)

Das Plugin benötigt ein gimp 2.2. Binaries gibt es für verschiedene Linux-Distributionen und Windows. Für Windows entpackt man das bereitgestellte Archiv und kopiert gimp-lqr-plugin.exe nach %USERPROFILE%\.gimp-2.2\plug-ins.

Debian Sid Nutzer finden das Plugin im Paket gimp-plugin-registry (seit Version 0.3.1-1). Damit steht einer automatischen Installation mittels aptitude nichts im Weg.
Nach einem Neustart von Gimp findet man das Plugin unter Ebene->Liquid Rescale.

Aber Achtung, so schnell wie im Video geht es bei weitem nicht. Man benötigt momentan noch viel Geduld. Hier auf einem Pentium M 1700 MHz mit 1 GB Ram dauerte es > 15 Minuten ein 6 MP Bild zu skalieren und der Rechner zeigt dabei deutliche Anzeichen eines Freeze (benötigte knapp 1 GB an Speicher!). Es mag aber sein, dass das mit neueren Gimp-Versionen bzw. einem neueren Plugin schneller geht.
Apropos, Gimp 2.4 steht kurz vor der Tür. Aktuell ist Gimp 2.4 (Release Candidate 3).

Nachdem mein bisheriger Brenner sich erfolgreich seit mehreren Jahren geweigert hat, DVDs zu brennen (trotz verschiedener Firmware-updates), hab ich ihn heute in den Ruhestand versetzt. Ich hatte bisher eigentlich immer den Verdacht, dass der Brenner nicht mit den Rohlingen zurecht kam, daher stapelten sich auf dem Schreibtisch jede Menge DVD-/+R und DVD-/+RWs.

Der neue Brenner ist ein Samsung SH-S182M und funktioniert hervorragend mit DVDs/CDs. Als kleinen Test hab ich bereits aus meinem Stapel leerer DVDs/CDs mehrere Images gebrannt.

Ich dachte ja, dass die Dinger teurer wären, denn ich rechnete so mit € 80-100, aber mittlerweile bekommt man gute und günstige Brenner bereits für € 30-45. Wenn ich das vorher gewußt hätte, hätte ich schon längst den alten ersetzt.

In letzter Zeit beochbachte ich auffallend oft, dass bei Bezahlung mit EC-Karte/Kreditkarte und Verifizierung mit Unterschrift, die Kassierer oftmals die Unterschrift gar nicht überprüfen. Sehr schön vor allem die Tankstellen, an denen man die Karte nichtmal dem Kassierer geben muss. Vermutlich bemerkt keiner, wenn nur mit 3 Kreuzen unterschrieben würde.

Ich dachte eigentlich immer, dass die Kassierer immer die Unterschrift mit der auf der Karte aufgedruckten überprüfen müssten.

Irgendwie nicht sehr vertrauenserweckend, da ist mir die PIN lieber.