Subversion+SSH über verschiedene SSH-Tunnel

Auf dem Server “duplo” im World Headquarter meiner kleinen Firma befindet sich unter /opt/svn ein Subversion-Repository. Neben dem Server steht eine Workstation namens “hanuta”, von der aus ich das Repository unter dem folgenden URL nutze: svn+ssh://duplo/opt/svn

Gleichzeitig besitze ich auch noch einen Laptop namens “rafaello”. Mit diesem bin ich immer in anderen Umgebungen unterwegs. Mal bin ich im Büro und kann direkt mit “duplo” reden, mal bin ich in der weiten Welt unterwegs und erreiche “duplo” über meinen DSL-Jumpserver in der Büro-DMZ, und manchmal bin ich beim Kunden und muß dort noch zusätzlich über einen SSH-Server in der DMZ des Kunden springen.

Um “duplo” auf diesen unterschiedlichen Wegen zu erreichen, habe ich eine ~/.ssh/config mit entsprechenden Host-Einträgen, in denen das jeweils passende ProxyCommand (darum soll es hier nicht gehen) aufgerufen wird:

• Ich tippe ssh duplo, wenn ich im Büro bin,

• ssh duplo-mobil, wenn ich unterwegs bin und
• ssh duplo-kunde, wenn ich beim jeweiligen Kunden bin.

Das Problem war nun, daß ich nicht wußte, wie ich mit dem ausgecheckten SVN-Repository umgehen sollte. Wenn ich im Büro ausgecheckt hatte und von unterwegs etwas einchecken wollte, mußte ich das Repository mit svn switch –relocate umschalten:
svn switch –relocate svn+ssh://duplo/opt/svn svn+ssh://duplo-mobil/opt/svn
Das hat irgendwie immer nur ein-bis zweimal funktioniert. Danach war die Arbeitskopie irgendwann in schwer nachvollziehbarer Weise verhunzt.

Glücklicherweise unterstützt SVN einen eigenen Tunneling-Mechanismus, der sehr gut mit dem ProxyCommand von SSH vergleichbar ist. Standardmäßig verwendet svn+ssh:// den Befehl ssh für den Zugriff aufs Repository. Dieser Aufruf von ssh kann mittels der Umgebungsvariable $SVN_SSH durch einen anderen ersetzt werden. Also z.B. wie folgt:

export SVN_SSH=”ssh -A duplo-mobil ssh”

Der Sicht aufs Repository erfolgt dann über localhost: svn info svn+ssh://localhost/opt/svn - In Wirklichkeit heißt das, daß eine Verbindung zu duplo-mobil aufgebaut wird, und von dort eine SSH-Verbindung auf den Host aus dem URL aufgebaut wird. In diesem Fall ist das passenderweise localhost. Es könnte aber auch svn info svn+ssh://duplo/opt/svn dort stehen, denn duplo kann ohne Probleme eine SSH-Verbindung zu duplo selbst aufbauen, oder eben zu localhost.

Der gegenwärtige Aufenthaltsort im Netz kann somit über die Umgebungsvariable $SVN_SSH ausgewählt werden. Das Repository wird dabei unverändert über localhost erreicht. (Hierbei sollte nicht vergessen werden, daß es sich bei diesem localhost nicht um den eigenen Rechner handelt, von dem ein Port weitergeleitet wird, o.ä., sondern um den localhost aus Sicht des Servers, auf dem das SVN-Repository liegt.)

Alix-Update

Meine neue ALIX 2c3 ist da. Eine interessante Änderung zur bereits vorhandenen ALIX ist, daß der IDE-Port jetzt bestückt ist. Ein Bauteil im Wert von wenigen Cent, das die Maschine für viele Leute deutlich aufwerten dürfte.

Des weiteren habe ich mir eine Entwicklungs-VMware für OpenBSD aufgesetzt, in der ich jetzt Flashdist-Images selbst bauen kann. Einen herben minimalen Dämpfer hat die aktuelle Bastelwelle allerdings dadurch bekommen, daß das bei Ubuntu mitgelieferte Minicom so miserabel ist, daß es nicht mal das kann, was es eigentlich sollte, nämlich ein Terminal emulieren:

Willkommen zu minicom 2.3-rc1

Optionen: I18n
Übersetzt am Dec 10 2007, 10:36:19.
Port /dev/ttyS0

               Drücken Sie CTRL-A  Z für Hilfe zu speziellen Tasten

minicom: ../iconv/loop.c:430: internal_utf8_loop_single: Assertion `inptr - bytebuf > (state->__count & 7)' failed.
                                   Aborted
martin@ubuntu:~$

Unfaßbar, ganz ehrlich. Und natürlich mal wieder eine Beta, was sonst, bei einem Produkt, das seit Jahren keine Innovation nötig hätte, auf die die ganze Welt gespannt warten würde.

Die massiven Paketverluste, die ich in zwei Wellen mit der m0n0wall-Beta hatte, treten leider auch unter OpenBSD auf. Eine Rücksprache mit dem Flashdist-Maintainer ergab, daß das durchaus darin liegen könnte, daß FreeBSD und OpenBSD den selben Hardwaretreiber für die “Via Rhine”-Netzwerkkarte benutzen. Hilfe ist aber auf dem Weg, denn bei FreeBSD wurde bereits eine komplette Neuentwicklung eingecheckt. Mal abwarten, wann die ihren Weg zu OpenBSD findet. Jedenfalls bin ich mit dem Problem nicht allein (es tritt auch auf Soekris-Hardware auf), und meine Hardware ist nicht defekt. Das beruhigt zumindest etwas.

Wenn der Glaube schwindet

Oh weh. Vorgestern glaubte ich noch, ich sei auf der sicheren Seite. Gestern fiel mir dann der Kunde ein, der Kommerzzertifikate im Gesamtwert von ca. 10.000 Euro auf einer Debian-Gurke generiert und verteilt hat. Gleich geht’s hin. Die Begeisterungsstürme werden gewaltig sein.

Aus dem Ding kommt Debian so schnell nicht raus. Nach dem allgemeinen Security-Debakel von vor drei Jahren ist man, nüchtern betrachtet, auch nicht gut damit beraten, Debian noch immer die Treue zu halten.

Der Amerikaner bemüht gern ein angeblich chinesisches Sprichwort: “Fool me once, shame on you. Fool me twice, shame on me.” - Dem ist in diesem Fall nichts hinzuzufügen.

Das jüngste Gerücht

Bei mir kam gerade das Gerücht vorbei, es solle heute bei Debian ein Announcement hinsichtlich eines nur relativ aufwändig zu fixenden Sicherheitsproblems durchkommen. Ich selbst habe derzeit kein Debian am Internet. Nur ein internes System, das per Jumpserver erreicht wird. Wer Debian am Start hat, sollte heute wohl besser Augen und Ohren offenhalten und den Nachmittag nicht zu straff durchplanen.

Update, 15:00, da isses:

————————————————————————
Debian Security Advisory DSA-1571-1                  security@debian.org
http://www.debian.org/security/                           Florian Weimer
May 13, 2008                          http://www.debian.org/security/faq
————————————————————————

Package        : openssl
Vulnerability  : predictable random number generator
Problem type   : remote
Debian-specific: yes
CVE Id(s)      : CVE-2008-0166

Luciano Bello discovered that the random number generator in Debian’s
openssl package is predictable.  This is caused by an incorrect
Debian-specific change to the openssl package (CVE-2008-0166).  As a
result, cryptographic key material may be guessable.

This is a Debian-specific vulnerability which does not affect other
operating systems which are not based on Debian.  However, other systems
can be indirectly affected if weak keys are imported into them.

It is strongly recommended that all cryptographic key material which has
been generated by OpenSSL versions starting with 0.9.8c-1 on Debian
systems is recreated from scratch.  Furthermore, all DSA keys ever used
on affected Debian systems for signing or authentication purposes should
be considered compromised; the Digital Signature Algorithm relies on a
secret random value used during signature generation.

The first vulnerable version, 0.9.8c-1, was uploaded to the unstable
distribution on 2006-09-17, and has since propagated to the testing and
current stable (etch) distributions.  The old stable distribution
(sarge) is not affected.

Affected keys include SSH keys, OpenVPN keys, DNSSEC keys, and key
material for use in X.509 certificates and session keys used in SSL/TLS
connections.  Keys generated with GnuPG or GNUTLS are not affected,
though.

A detector for known weak key material will be published at:

    (OpenPGP signature)

Instructions how to implement key rollover for various packages will be
published at:

This web site will be continously updated to reflect new and updated
instructions on key rollovers for packages using SSL certificates.
Popular packages not affected will also be listed.

In addition to this critical change, two other vulnerabilities have been
fixed in the openssl package which were originally scheduled for release
with the next etch point release: OpenSSL’s DTLS (Datagram TLS,
basically “SSL over UDP”) implementation did not actually implement the
DTLS specification, but a potentially much weaker protocol, and
contained a vulnerability permitting arbitrary code execution
(CVE-2007-4995).  A side channel attack in the integer multiplication
routines is also addressed (CVE-2007-3108).

For the stable distribution (etch), these problems have been fixed in
version 0.9.8c-4etch3.

For the unstable distribution (sid) and the testing distribution
(lenny), these problems have been fixed in version 0.9.8g-9.

We recommend that you upgrade your openssl package and subsequently
regenerate any cryptographic material, as outlined above.
[...]

Betroffen sind also alle SSH-Keys (Host und Identity), und alle X.509-/SSL-Zertifikate, egal ob Server-, Client- oder CA-Zertifikat, die auf einem Debian-System erstellt wurden. Nur GnuPG ist sauber, da man sich dort nicht auf fremde Crypto-Libs verläßt.

Das riecht nach richtig viel Arbeit, Leute.

They’re actually schlepping!

Wie es (vielleicht auch nicht) ausgesehen hätte, wenn Starbucks schon vor 10 Jahren der Inbegriff für “Internetkaffee” gewesen wäre, zeigt dieser nette Röhrenmonitor-Flashmob bei Youtube: Mobile Desktop (Nein, kein Embed, da hab ich kein Bock drauf.)

“Three agents entered a Starbucks one by one with their own giant desktop computer and CRT monitor rig. They bought coffee and worked at their computers as if they were laptops. One computer even had a Wi-Fi card installed, enabling our agent to surf the web.”

Der Netzsheriff findet es bemerkenswert, daß kein Terroralarm ausgelöst wurde. Wenn das Bahnkunden in der DB-Lounge gewesen wären, hätten sie aber mindestens mal eine Anzeige wegen Stromdiebstahl abgekriegt.

Nichtdruckbare Zeichen in vi anzeigen

Ehrlich? Ich habe grade mal keine Ahnung, wie man nichtdruckbare Zeichen in vi anzeigen kann. Aber wenn die Unterscheidung von Tab und Leerzeichen und die Erkennung von Leerzeichen am Zeilenende ausreichen, dann tut es auch folgende Option:

:set list

Es handelt sich dabei übrigens nicht um ein vim-Feature, sondern gewissermaßen um “vi classic”.

Tücke der Klimatechnik

Acht Jahre lang habe ich den ganzen Sommer über mit dem Erkältungstod gerungen, weil es kein Entkommen vom Luftstrom der Klimaanlage gab. Heute stelle ich heute fest, daß das Klimagerät hinter den äußeren, per Fernbedienung höhenverstellbaren, Lamellen, auch innere Lamellen hat, mit denen man den Luftstrom seitlich variieren kann. Ich komme mir grade mal sehr, sehr dämlich vor.

Swap im Reality Check

Swap unter Linux scheint so eine Sache zu sein, um die sich reichlich Mythen und Legenden ranken. Deshalb schreibe ich heute mal auf, was ich so von der Sache halte.

Wie wir alle wissen, wird der Swap-Bereich zusammen mit dem realen Arbeitsspeicher (RAM) zum sogenannten Virtual Memory (VM) zusammengefaßt. Auf einem System mit 2 GB RAM und 2 GB Swap steht also ein für Appikationen nutzbares VM von 4 GB zur Verfügung. Die Hälfte davon befindet sich als Swap auf Festplatte. Zugriffe darauf sind sehr viel langsamer als Zugriffe auf den normalen Arbeitsspeicher.

Mythos: “Jedes UNIX-System braucht Swap!”

Swap ist nicht mehr als eine sehr, sehr langsame Speichererweiterung. Ist der Arbeitsspeicher voll, werden Speichersegmente auf Festplatte ausgelagert. Dadurch, daß diese Auslagerung deutlich langsamer als normale RAM-Aktiviät geschieht, wird das System in aller Regel extrem langsam. Diese Auslagerungsaktivität kann im Rahmen einer Überwachung erkannt werden. Idealerweise wird auch die Problemquelle identifiziert und der entsprechende Prozeß von Hand beendet, so daß das System weiterlaufen kann.

Daraus folgt im Prinzip nichts anderes, als daß Swap nichts weiter bringt, als einen gefühlten Zeitgewinn für das Beenden von Speicherfressern.

Auf der Hand liegt andererseits auch, daß man z.B. ein Flash-basiertes (und damit read-only)-System ohne Swap betreiben können muß. Folglich gilt, daß ein Linux-System ohne Swap problemlos laufen kann, solange der Arbeitsspeicher für den gesamten Speicherbedarf aller zu benutzenden Applikationen ausreichend dimensioniert ist.

Mythos: “Swap muß immer auf einer eigenen Partition liegen!”

Unter Linux (und vermutlich auch den meisten anderen UNIX-Systemen) ist es problemlos möglich, anstelle einer Swap-Partiton ein Swapfile zu verwenden. Die Vorgehensweise dazu ist dort in der Manpage von mkswap beschrieben. Da ein swappendes System ohnehin ein schweres Problem mit der Performance von Speicherzugriffen hat, kann man den marginalen zusätzlichen Performanceverlust durch die Dateisystemebene praktisch vernachlässigen. (Eine Ausnahme gilt, die erwähne ich im übernächsten Absatz.)

Mythos: “Es muß immer doppelt soviel Swap vorhanden sein, wie Arbeitsspeicher!”

Das ist so eine ganz alte Daumenregel, deren historischer Hintergrund schwer durchschaubar ist. Sie ist vermutlich teilweise darin begründet, daß es UNIX-Systeme gegeben haben soll, bei denen der Arbeitsspeicher auf Swap gespiegelt wurde. Um also eine wirksame Vergrößerung des VM durch Swap zu haben, war also wesentlich mehr Swap als Arbeitsspeicher erforderlich.

Eine Mindestgröße für Swap ergibt sich bei tragbaren Systemen, die für die Hibernation ihren Arbeitsspeicher auf Swap auslagern. Dies ist meines Wissens die einzige Situation, in der nicht nur eine wirkliche Mindestgröße für Swap vorliegt, sondern in der es sich auch tatsächlich um eine Swap-Partition handeln muß.

Generell gilt, daß es über die altbekannte Daumenregel hinaus keine feststehende Regel für die Swap-Größe gibt. Wer sich an der alten Regel festhalten will, darf das gern tun. Man sollte sich aber durchaus fragen, welche Dinge man von einem System mit 8, 16 oder 32 GB Swap zu erwarten glaubt.

Mythos: “Aber tmpfs braucht Swap!”

Nur um dem unvermeidlichen Kommentar vorzubeugen: Das tmpfs-Dateisystem, z.B. unter Solaris und Linux, braucht nicht Swap, sondern Virtual Memory. Es wird also bei ausreichenden Platzverhältnissen im Arbeitsspeicher gehalten, kann aber von Applikationen auf Swap verdrängt werden. Es stellt sich die Frage, inwieweit ein dediziertes Filesystem für /tmp überhaupt eine Berechtigung hat, wenn seine Schreib- und Leseperformance im Prinzip unvorhersagbar sind.

Ubuntu 8.04

Ubuntu Horny Hard-on. The pr0n release.

Der Inside-Job

$KUNDE hielt heute mit der Freitagnachmittags-Bierflasche in der Hand eine bewegende Rede ans Volk, an deren Rande er betonte, daß er jedem aus seiner bunten Beratertruppe, der sich auf “Hackerkongressen” aufhält, während gegen seine Infrastruktur irgendwelche Angriffe gefahren werden, auf der Stelle Hausverbot erteilen wird.

Später habe ich dann erfahren, daß ein ehemaliger freier Mitarbeiter des Ladens, kein pickliger Jüngling, sondern ein Kollege im gestandenen Mannesalter (ich durfte ihn vor seinem Abschied noch kurz kennenlernen), es tatsächlich geschafft hat, mit seinem Insiderwissen vom 24. Chaos Communication Congress aus eine Webserverfarm des Kunden auszuknipsen, für deren Inbetriebnahme er zuständig gewesen war. Daraufhin kam die Welt zum Stillstand und wegen der Urlaubssaison war niemand zu erreichen, so daß die Website einen Tag lang offline war. Der Experte, der am meisten über die Serverfarm wußte und sie wieder auf die Beine hätte stellen können, war der Angreifer ja immerhin selbst, und der weilte auf Urlaub in Berlin.

Anschließend hat er alles zugegeben, als “Penetration Test” deklariert und zu seiner Verteidigung vorgebracht, daß der dämliche ISP des Kunden überreagiert habe und das alles doch nur Spaß und Spiel war. (Die Story ist plausibel und ich hatte sie bereits aus anderer Richtung schonmal so ähnlich gehört.)

Oh, verdammt.

1) Hat er als Insider das Vertrauen seiner Kundschaft nicht nur mißbraucht, sondern diese auch noch vorsätzlich geschädigt.
2) Wie das technisch aussah, spielt dabei eigentlich keine Rolle. Wenn er Sicherheitsprobleme kennt, sollte er sie nicht exploiten, sondern fixen. Das ist seine Pflicht.
3) Ist der CCC, der noch nie ein “Chaos-Club” war und sich derzeit notgedrungen vom “Computer-Club” zur techniklastigen Bürgerrechtsorganisation umzubauen scheint, in den Augen dieses Kunden eine kriminelle Chaosgruppe. Wie aus dem dümmsten Klischeebaukasten der Achtziger, und das auch noch verständlicherweise.
4) Hat er dafür gesorgt, daß Personen aus dem CCC-Umfeld bei diesem Kunden nun unter Generalverdacht stehen.

Das schlimme ist nicht, daß er das ganze rumerzählt hat, sondern das schlimme ist, daß er es getan hat. Wirklich eine grandiose Leistung. Eines Hackers ist das nicht würdig.