Lustige Portweiterleitungen

Unsere Schulhomepage besitzt einen eigenen Loginbereich, für den wir gerne auch die Nutzername/Passwortwortkombination nutzen wollten wie für den Schulserver. Mehrere unterschiedliche Zugänge sind in der Regel nutzerunfreundlich und werden kaum akzeptiert.

Das verwendete Joomla! hat zum Glück eine Reihe von Authentifizierungsplugins, unter anderem LDAP, POP3, IMAP oder Keberos. Am einfachsten geht es über IMAP, d.h. Joomla! versucht sich mit den Nutzerdaten bei Mailserver des Schulservers einzuloggen und wenn das klappt, legt es einen neuen Benutzeraccount an, den es zukünftig immer extern authentifiziert. Dummerweise klappte das bei uns nur über eine unverschlüsselte Verbindung zuverlässig – also keine sinnvolle Option.

Glücklicherweise läuft unser Joomla! auf einem VServer, auf den wir Shellzugriff haben. Mit einem linuxtypischen Einzeiler kann man den Mailserverport durch einen verschlüsselten Kanal auf den VServer tunneln – bei uns:

ssh -R 1143:localhost:143 unprivileged@vserver.xy -N -T

Das sorgt dafür, das der unverschlüsselte Mailserverport 143 auf dem VServer unter der Portnummer 1143 erreichbar ist.

Normalerweise würde nach diesem Kommando das Passwort des Benutzer „unprivileged“ (der Nutzer sollte möglichst wenig Rechte auf dem Zielserver haben, weshalb die Portnummer auch größer als 1024 sein muss) erfragt werden. Damit das nicht geschieht, verwenden wir die Authentifizierung per Public-Key.

Unser Schulserver ist nur per VDSL an das Internet angebunden und wird einmal täglich providerseitig vom Netz getrennt. Damit würde unser Tunnel zusammenbrechen. Damit das erkannt wird, läuft folgendes Script per cronjob alle fünf Minuten:

#!/bin/bash
COUNT=`ps aux | grep unprivileged | wc -l`
if [ $COUNT -ge 2 ]; then
exit 0
else
ssh -R 1143:localhost:143 unprivileged@vserver.xy -N -T
fi

Die Variable COUNT enthält die Ausgabe der Befehlspipe zwischen den Backticks `. Wenn der Tunnel offen ist, enthält die Ausgabe zwei Zeilen (den eigentlichen Tunnelprozess und den Suchprozess nach „unprivileged“). Wenn das so ist, tut das Script nichts, wenn nicht, startet es den Tunnel einfach neu. Das Script muss mit Rootrechten laufen, da ein Port unterhalb von 1024 lokal verwendet wird.

Auf diese Weise kann man im Prinzip jeden Dienst lokal auf einen VServer weiterleiten, z.B. auf den LDAP der Musterlösung aus Baden-Württemberg und muss dann keine Klartextpasswörter mehr durch die Gegend schicken.

Asymmetrische Verschlüsselung mit SSH

Es gibt zwar zu diesem Thema viele Tutorials im Netz, jedoch konnte ich mir bisher keines so richtig merken.

Was kann man damit eigentlich anstellen?

Normalerweise logge ich mich in einen Server mit einem Benutzernamen und einem Passwort ein. Der Server überprüft dann, ob mein eingegebener Benutzername zum auf dem Server gespeicherten Passwort (meist ein Hash) passt und gewährt mir im positiven Fall dann Zugriff. Das lässt sich eigentlich ganz gut mit einem Zahlenschloss an einem Fahrrad vergleichen: Nur wer die korrekte Kombination kennt, kann dieses Schloss öffnen. Bei einem Fahrradschloss kann ich als böser Bube jedoch durch Ausprobieren die korrekte Kombination herausfinden. Das ist lediglich eine Frage der Zeit. Je einfacher mein Passwort aufgebaut ist (etwa „3333“, desto weiniger Zeit wird der Angreifer benötigen.

Aufgrund dieser Problematik wurde im Serverbereich die Authentifizierung via Schlüssel (Key) erfunden. Das Verfahren ist eigentlich sehr pfiffig: Der Benutzer generiert zunächst einmal zwei Schlüssel: Einen privaten und einen öffentlichen. Bei der Anmeldung am Server geschieht nun folgendes:

Der Benutzer sendet seinen Benutzernamen, der aber mit mit seinem privaten Schlüssel verschlüsselt (unkenntlich gemacht) ist. Der Server besitzt den öffentlichen Schlüssel und den Benutzernamen des Benutzers. Bei ihm kommt nun eine kryptische Zeichenkette an, die er nur mit dem öffentlichen Schlüssel wieder in den Benutzernamen umwandeln kann. Die öffentliche Schlüssel muss zu dem privaten Schlüssel passen. Zudem taugt der öffentliche Schlüssel nur zur Entschlüsselung, nicht jedoch zur Verschlüsselung.

Um ganz genau zu sein (Danke Markus…):

Speziell bei SSH ist es nun so, dass die asymmetrische Verschlüsselung nach diesem Verfahren nur verwendet wird, um einen Schlüssel für eine performantere synchrone Verschlüsselung auszuhandeln. Nach dem Handshake machen Server und Client also „ihr eigenes Ding“.

Vorteil:

Nur wer im Besitz des privaten Schlüssels ist, kann sich am Server anmelden. Das Ausprobieren von Passworten ist theoretisch nicht denkbar (man müsste die Verschlüsselung imitieren), aber praktisch immens schwierig und zeitaufwendig.

Ein Bild für dieses Verfahren ist z.B. ein Fahrradschloss mit Schlüssel. Der private Schlüssel hängt am Schlüsselbund des Benutzers. Die Schlossmechanik selbst ist der öffentliche Schlüssel und weit aufwendiger zu imitieren als etwa eine Zahlenkombination herauszufinden.

Natürlich kann man mit dem Verfahren nicht nur Benutzernamen, sondern alle möglichen Texte verschlüsseln. – z.B. auch E-Mails. Den öffentlichen Schlüssel kann man gefahrlos weitergeben, sodass sich den jeder Empfänger herunterladen kann.

Hier einmal ein einfaches Schaubild:

Wie funktioniert das nun praktisch?

Weiterlesen