Stephan Paukner :: syslog

This official Debian manual explains how to set up an SSH server in a chroot. However, and although it was last modified in March 2009, the manual appeared incomplete to me. Here are a few additional steps to consider:

The manual uses makejail (and the config /usr/share/doc/makejail/examples/sshd.py) to automatically set up /var/chroot/sshd; the script uses ldd calls to find and copy the necessary libraries and files. However, its work is incomplete: You can’t launch the chroot’s Bash. Even /bin/ls doesn’t work. Using ldd I found out that /lib64/ld-linux-x86-64.so.2 is missing in the chroot.

To use an elegant /etc/init.d/ssh-chroot script to control the chroot’ed daemon from the host system, you need to make /sbin/start-stop-daemon available in the chroot. You can then use /etc/init.d/ssh as basis for your init-script. Note that the chroot-SSH takes its config from /var/chroot/sshd/etc/ssh/sshd_config; it is possible to have both the native and the chroot’ed SSH daemon listen on port 22, but on different IPs.

The manual mentions that proc must be mounted in the chroot as well and that syslogd should also lay a sock in there. But it doesn’t mention that devpts must be mounted in /var/chroot/sshd/dev/pts. Add this to the host’s /etc/fstab with the options noexec,nosuid,gid=5,mode=620; make the tty group available in /var/chroot/sshd/etc/group!

If you make strace work in the chroot, you can find out via

and looking into /var/log/auth.log that the /etc/pam.d/common-* stuff is missing.

Having considered this, login should finally work if you have users and groups in /var/chroot/sshd/etc/{passwd,shadow,group}. You might need the coreutils in the chroot; you can install them using the makejail config mentioned above.

Ich hab’ gleich mal die nächste Baustelle aufgerissen: Ich habe eine neue e-card zugeschickt bekommen, weil „sie“ jetzt plötzlich auf meinen akademischen Titel draufgekommen sind, den ich eh schon seit 1½ Jahren habe. Auch gut. Jetzt muss ich allerdings die Bürgerkartenfunktionalität auf die neue Karte übertragen. Diejenigen, die selbst eine Bürgerkarte besitzen, verspüren nun sicherlich so wie ich einen Stich im Arsch: „Au weh! Wird das denn funktionieren? Wie kompliziert wird das wieder werden? Wieviele unbekannte SSL-Zertifikate muss ich wieder akzeptieren? Werden mich die Links mit Fehlermeldungen wieder im Kreis leiten?“ Und vor allem: „Wird das Internet überhaupt jemals wieder gehen?“

Die letzten Schmerzen zu dem Thema habe ich mir allerdings selbst zugefügt, weil ich nicht bemerkt hatte, dass 32 ungleich 64 ist; ich hatte nämlich versucht, die bisherige 32-bit Java-Bürgerkartensoftware mit einem 64-bit Java weiterzuverwenden, was mich mindestens eine Stunde gekostet hat.

Um die neue Karte nun ebenfalls als Bürgerkarte zu aktivieren – ein Übertragen der Zertifikate ist nämlich nicht möglich – habe ich mich nun zunächst mit der alten Bürger-e-card im FinanzOnline eingeloggt, um die Funktionalität zu verifizieren, was auch wunderbar funktioniert hat. Also andere Karte in den Leser, herkömmlich dort einloggen und Bürgerkarte aktivieren. Natürlich wurde ich wieder im Kreis geleitet, nämlich mit dem relativ schlichten Hinweis, ich möge doch nochmal von vorne anfangen, da irgendwas schiefgegangen sei. Klar, das NoScript-Addon meines Feuerhundes hatte ich sowieso schon zuvor deaktiviert. Aber wieso geht das Internet mit der neuen Karte nicht?

Da fiel mir meine Konfigurationsänderung von gestern ein: Ich habe den userAgent-String auf „Firefox Windows (fake)“ geändert. Ob das denn einen Einfluss haben könnte? Na gut, als alter Linuxer probiert man bald die unmöglichsten Dinge aus, wenn irgendwas mal wieder nicht geht. Und tatsächlich: Stellt sich mein Browser wieder mit dem richtigen Namen vor, klappt’s auch mit der Bürgerkarten-Aktivierung. Ich sollte langsam aufhören mich zu wundern.

Am Weg zu meinem ultimativen Anti-WWW-Rant liegt z.B. folgender Fall: Ich habe nun doch mal dem A1-Service eine Mail gesandt mit dem Hinweis, dass deren Webshop bei mir nur mit Überschriften und ohne eigentlichen Inhalt erscheint, obwohl mein Browser weder zu alt noch zu jung und mit den üblichen Plugins und Funktionen (JavaScript, Flash, Video, whatever) ausgestattet ist.

Deren Antwort:

danke für Ihr E-Mail!

Wir können das beschriebene Problem leider nicht nachvollziehen. Getestet wurde auf Windows XP, Vista auf aktuellen Servicepacks und mit Mac OS 10.5.6 bzw. unter Verwendung der aktuellen Versionen von Internet Explorer und Mozilla Firefox.

Haben Sie noch Fragen? Wir sind gerne für Sie da.

Meine Antwort:

Hab’s mir etwas genauer angesehen. Offenbar checkt das Javascript (env.js) zu rigide nur auf die Betriebssysteme Windows und MacOS, sowie auf gewisse Browsernamen. Linux wird in den Funktionen nicht berücksichtigt, wie auch nicht „Mozilla“ oder „Iceweasel“. Vermutlich ist dadurch dann das Objekt A1data undefiniert (data.js, util.js).

Andere Websites, die nicht so rigide einschränken, funktionieren „auf gut Glück“ in beliebigen Mozilla-Derivaten, egal welches OS.

Ich habe testhalber meine Browserkennung gefälscht (schlicht auf „Firefox Windows (fake)“), um die Funktionen zu überlisten. Und siehe da, plötzlich funktioniert der Webshop!

Der Browsercheck ist nicht so intelligent wie er gerne wäre. Die Webprogrammierer sollten mehr den Mozilla-Derivaten vertrauen.

Mein normaler userAgent-String:
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.11) Gecko/2009061208 Iceweasel/3.0.6 (Debian-3.0.6-1)