Information & Consulting

Heute gab es die Aufgabe, auf einem Rechner mit aktuellem Debian GNU/Linux-System, den SSH-Agent beim Einloggen zu starten. Das Ziel ist, beim Einloggen einmal an zentraler Stelle den Schlüssel zu entsperren und Public-Key-Authentication ohne erneute Eingabe des Paßworts zu ermöglichen.

Dazu muß beim Anmelden ans System innerhalb von KDE der SSH-Agent gestartet werden. Das erfolgt in einem Terminal mit folgendem Befehl:

ssh-add < /dev/null

Ist das Paket ksshaskpass installiert, wird automatisch ein KDE-Programm gestartet, das nach der Passphrase fragt, um den Schlüssel zu entspreren und mit dem kWallet zu verknüpfen.

Über das KDE-Menü, Systemeinstellungen gelangt man zu einem Dialog "Starten und Beenden", in dem im Abschnitt "Autostart" die Programme verwaltet werden, die beim Start des KDE-systems automatisch gestartet werden.

Das dort eingetragene Skript, das lediglich den obigen Code enthält, wird nur leider beim nächsten Einloggen nicht ausgeführt. Der Eintrag in diesem Dialog verschwindet auch wieder.

Zum Erfolg führt letztendlich der klassische Weg unter Umgehung aller schöner fancy Desktop-Möglichkeiten. Das bereits genannte Skript wird klassisch in das Verzeichnis .kde/Autostart verschoben. Das Skript muß natürlich als ausführbar markiert sein.

Beim nächsten Start von KDE öffnet sich dann der Dialog zum Entsperren des SSH-Schlüsels, so daß die Paßwort-lose Public-Key-Authentication genutzt werden kann.

Der Dialog für die Auswahl der angezeigten Spalten bei OpenRico 2.1 unterstützt zwar vertikales Scrollen des Browsers bei der Positionierung, nicht aber horizontales Scrollen.

Dieser Patch paßt die horizontale Position des Popups der aktuellen Scroll-Position an.

Aktuelle Versionen von OpenSSL akzeptieren keine Passwörter mit weniger als 4 Zeichen. Das ist im Prinzip auch gut und sorgt für halbwegs ordentlich geschützte Schlüssel.

Das ganze wird allerdings zu einem Problem, wenn der Schlüssel bereits mit einem kürzeren Passwort erzeugt wurde und nun nachträglich ein längeres Paßwort (oder keins) gesetzt werden soll. OpenSSL quittiert die Eingabe des (leider korrekten) Paßworts mit einer Fehlermeldung:

openssl rsa -in key.pem -out key-newpass.pem
Enter pass phrase for key.pem:
139909046961832:error:28069065:lib(40):UI_set_result:result too small:ui_lib.c:869:You must type in 4 to 8191 characters
Enter pass phrase for key.pem:

Dem Problem kann man dadurch begegnen, daß die Paßwörter nicht vom Terminal gelesen werden sondern vorher in einer Umgebungsvariable gespeichert werden. Der folgende Befehl löscht demzufolge das Passwort

export SSLPASS=pw
openssl rsa -passin env:SSLPASS -in key.pem -out key-nopass.pem

Und dieser setzt ein neues Passwort

export SSLPASS=pw
export SSLPASSNEW=geheim
openssl rsa -passin env:SSLPASS -passout env:SSLPASSNEW -in key.pem -out key-newpass.pem

Der große Vorteil von OpenWrt ist das offene System inklusive cron, shell und diversen Skript-Möglichkeiten. Allerdings gibt es einen Unterschied zwischen der Ausführung von ssh in einem Hook-Skript und in einer interaktiven Shell.

In der interaktiven Shell kann die Authentizität des entfernten Rechners bestätigt werden, im Skript ohne Terminal ist das nicht möglich.

Wenn man sich stderr ansieht, wird man folgendes finden

Host 'remote-server' is not in the trusted hosts file. (ssh-rsa fingerprint md5 de:ad:be:af:ff:48:47:ed:c5:d6:de:ad:be:af:ff:ce)
Do you want to continue connecting? (y/n)
ssh: Connection to remote-server exited: Didn't validate host key

Während in einer interaktiven Shell die Datei /root/.ssh/known_hosts gelesen und der Fingerprint damit verglichen wird, passiert das im nicht-interaktiven Modus innerhalb eines Skripts nicht.

Die Lösung besteht leider darin, die Host-Authentifizierung mit dem Parameter -y zu deaktivieren.

Ich habe mehrere Anfragen erhalten, das vorgegebene Layout (CSS) vom MoinMoin-Wiki anzupassen. Die vom Projekt vorgeschlagene Anleitung sagte allerdings nicht, zu, da man damit in das MoinMoin-System direkt eingreifen muß - und das liegt unterhalb von /usr und damit in der Hoheit der Distribution und nicht des lokalen Administrators.

Gesucht wurde daher eine andere Möglichkeit, auf das CSS Einfluß zu nehmen. Am besten wäre gewesen, man könnte in der Konfiguration zusätzliche Codezeilen in den Kopf der Seiten einfügen. Vielleicht gibt es diese Möglichkeit in einer zukünftigen Version ja.

Da das bisher nicht möglich ist, verwenden wir einen kleinen Trick. Ausgeliefert werden die Wiki-Seiten sowieso über einen Apache-Webserver und der bietet vielfältige Möglichkeiten. Es wird dort ein Alias eingefügt, der auf eine PHP-Datei verweist, die für eine CSS-Datei die ursprüngliche Datei einliest und erweitert.

Die Konfiguration des Webservers sieht wie folgt aus:

<VirtualHost wiki.domain.de>
  Alias  /moinstatic/modern/css/screen.css       /var/www/wiki-localcss.php
</VirtualHost>

Die PHP-Datei sieht dann wie folgt aus:

<?php>

header('Content-type: text/css');
$css = file_get_contents('/usr/share/moin/htdocs/modern/css/screen.css');
echo $css . "\n";

echo <<<EOC
#pageinfo {
    float: none;
    text-align: right;
}
table.navigation {
    float: none;
}
EOC;

Hier wird gleichzeitig die Navigation der Kindseiten nach links gezogen und die Seiteninformationen nach rechts geschoben.

Auf einem Server hatten wir arge Probleme, da das automatische Upgrade nicht geklappt hat und niemand mehr Zugriff auf seine Mailboxen hatte. Alle Recover-Werkzeuge (z.B. ctl_cyrusdb und cyrreconstruct oder ctl_mboxlist) sind mit einem Segmentation Fault abgestürzt.

Das Verzeichnis /var/lib/cyrus/db wurde schon gelöscht.

Der Grund war wohl eine defekte mailboxes.db-Datei. Diese mußte also neu erstellt werden.

Zum Glück hat Cyrus für alle User die Namen der meisten Folder der IMAP-Konten gespeichert, so daß man mit dem folgenden Skript die Datei neu aufbauen kann.

#! /bin/sh

cd /var/lib/cyrus/user

find -name '*.sub' | while read path
do
    user=$(basename $path .sub)
    # echo $user $path
    while read folder
    do
	printf "%s	0 default %s	lrswipcda	\n" "$folder" $user
    done < $path
done | (cd /var/lib/cyrus; /usr/lib/cyrus/bin/ctl_mboxlist -u)

Anschließend blieb noch ein Problem, Cyrus hat dauernd die restlichen DB-Dateien neu erstellt, weil eine Pivot-Datei fehlt. Im Syslog taucht folgende Meldung auf:

DBERROR: reading /var/lib/cyrus/db/skipstamp, assuming the worst: No such file or directory

Hier ist die Lösung ganz einfach:

install -o cyrus -g mail -m 600 /dev/null /var/lib/cyrus/db/skipstamp

Nach Upgrade auf die neueste Version von Apache und PHP5 wurden die virtuellen Hosts nicht mehr erkannt, was zu einiger Verwirrung geführt hat. Die Ursache ist, daß die Konfigurationsdateien für die virtuellen Hosts nicht mehr erkannt werden, da die Dateien jetzt auf ".conf" enden müssen.

Die vom Debian-Paket mitgelieferte Default-Datei (Link 000-default) wird beim Upgrade des Pakets automatisch passend umbenannt. Das wird leider nicht mit den anderen Konfigurationsdateien gemacht, so daß sie nicht mehr erkannt werden. Lösung: Bei allen Dateien und Links in /etc/apache2/sites-enabled den Suffix .conf anhängen.

Die Anweisung NameVirtualHosts wird nicht mehr benötigt. Die neue Version vom Apache erkennt automatisch, daß mit Name-Based virtual hosts gearbeitet wird, wenn mehr als eine Konfiguration für Name:Port- bzw. IP:Port-Paare existiert.

Beim Upgrade der PHP5-Version ist ggf. auch Vorsicht geboten. Die Option

The plan was to install the new Icinga-Web interface together with PostgreSQL and Icinga on a Debian system looking at this description.

That alone caused AJAX backend calls to fail with this backtrace:

#0 /usr/share/icinga-web/lib/doctrine/lib/Doctrine/Connection/Mysql.php(101): Doctrine_Connection->connect()

#1 /usr/share/icinga-web/lib/doctrine/lib/Doctrine/Connection.php(1010): Doctrine_Connection_Mysql->connect()

#2 /usr/share/icinga-web/lib/doctrine/lib/Doctrine/Query/Abstract.php(976): Doctrine_Connection->execute('SELECT i.progra...', Array)

#3 /usr/share/icinga-web/app/modules/Api/lib/database/IcingaDoctrine_Query.class.php(116): Doctrine_Query_Abstract->_execute(Array)

#4 /usr/share/icinga-web/lib/doctrine/lib/Doctrine/Query/Abstract.php(1026): IcingaDoctrine_Query->_execute(Array)

#5 /usr/share/icinga-web/app/modules/Cronks/models/Provider/ProgramStatusModel.class.php(103): Doctrine_Query_Abstract->execute()

#6 /usr/share/icinga-web/app/modules/Cronks/models/Provider/ProgramStatusModel.class.php(88): Cronks_Provider_ProgramStatusModel->refresh()

#7 /var/cache/icinga-web/config/compile.xml_production__d41bc4e7416d79a2859fb497054ab4f5308e2df1.php(441): Cronks_Provider_ProgramStatusModel->initialize(Object(AppKitAgaviContext), Array)

#8 /usr/share/icinga-web/app/modules/Cronks/actions/Util/ReloadStatusAction.class.php(44): AgaviContext->getModel('Provider.Progra...', 'Cronks')

#9 /var/cache/icinga-web/config/compile.xml_production__d41bc4e7416d79a2859fb497054ab4f5308e2df1.php(949): Cronks_Util_ReloadStatusAction->executeRead(Object(AgaviWebRequestDataHolder))

#10 /var/cache/icinga-web/config/compile.xml_production__d41bc4e7416d79a2859fb497054ab4f5308e2df1.php(1463): AgaviExecutionContainer->runAction()

#11 /var/cache/icinga-web/config/compile.xml_production__d41bc4e7416d79a2859fb497054ab4f5308e2df1.php(1255): AgaviExecutionFilter->execute(Object(AgaviFilterChain), Object(AgaviExecutionContainer))

#12 /var/cache/icinga-web/config/compile.xml_production__d41bc4e7416d79a2859fb497054ab4f5308e2df1.php(1700): AgaviFilter->executeOnce(Object(AgaviFilterChain), Object(AgaviExecutionContainer))

#13 /usr/share/icinga-web/lib/agavi/src/filter/AgaviSecurityFilter.class.php(73): AgaviFilterChain->execute(Object(AgaviExecutionContainer))

#14 /var/cache/icinga-web/config/compile.xml_production__d41bc4e7416d79a2859fb497054ab4f5308e2df1.php(1255): AgaviSecurityFilter->execute(Object(AgaviFilterChain), Object(AgaviExecutionContainer))

#15 /var/cache/icinga-web/config/compile.xml_production__d41bc4e7416d79a2859fb497054ab4f5308e2df1.php(1700): AgaviFilter->executeOnce(Object(AgaviFilterChain), Object(AgaviExecutionContainer))

#16 /var/cache/icinga-web/config/compile.xml_production__d41bc4e7416d79a2859fb497054ab4f5308e2df1.php(870): AgaviFilterChain->execute(Object(AgaviExecutionContainer))

#17 /var/cache/icinga-web/config/compile.xml_production__d41bc4e7416d79a2859fb497054ab4f5308e2df1.php(1266): AgaviExecutionContainer->execute()

#18 /var/cache/icinga-web/config/compile.xml_production__d41bc4e7416d79a2859fb497054ab4f5308e2df1.php(1255): AgaviDispatchFilter->execute(Object(AgaviFilterChain), Object(AgaviExecutionContainer))

#19 /var/cache/icinga-web/config/compile.xml_production__d41bc4e7416d79a2859fb497054ab4f5308e2df1.php(1700): AgaviFilter->executeOnce(Object(AgaviFilterChain), Object(AgaviExecutionContainer))

#20 /usr/share/icinga-web/lib/agavi/src/filter/AgaviFormPopulationFilter.class.php(78): AgaviFilterChain->execute(Object(AgaviExecutionContainer))

#21 /var/cache/icinga-web/config/compile.xml_production__d41bc4e7416d79a2859fb497054ab4f5308e2df1.php(1700): AgaviFormPopulationFilter->executeOnce(Object(AgaviFilterChain), Object(AgaviExecutionContainer))

#22 /var/cache/icinga-web/config/compile.xml_production__d41bc4e7416d79a2859fb497054ab4f5308e2df1.php(579): AgaviFilterChain->execute(Object(AgaviExecutionContainer))

#23 /usr/share/icinga-web/pub/index.php(49): AgaviController->dispatch()

#24 {main}