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.
This work by Maik Riecken is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International
Kleiner Tipp: Ich benutze privat autossh. Das macht das ganze automatisch als Dienst.
http://www.debianadmin.com/autossh-automatically-restart-ssh-sessions-and-tunnels.html
Ich nehme an, dass ihr den SSH-Zugang über Zertifikate abfrühstückt oder?
Wäre erwähnenswert.
Danke für den Tipp mit autossh. Zertifikate? Wir nutzen Public-Key-Authentifizierung. Zertifikate kenne ich in Zusammenhang mit SSH jetzt nicht … Aber natürlich erzwingt der Webserver standardmäßig https.
Genau.
Es gibt private Zertifikate (Private key) und öffentliche (Public Key). D. h. es geht nur mit beiden.
Hier zum nochmals nachlesen: https://de.wikipedia.org/wiki/Digitales_Zertifikat
Ok. Dann habe ich einen Denkfehler. Bisher habe ich immer gedacht, dass im SSH-Protokoll zunächst der Serverkey an den Client übermittelt und vorerst zur Absicherung der Verbindung genutzt wird (der den in der Regel gepinnt hat und so ggf. Man-in-the-middle-Attacken erkennt).
Nach diesem Handshake wird die Authentifizierung durchgeführt – entweder mittels eines asymmetrischen Schlüsselpaares oder per Credentials.
Danach handeln Server und Client einen symmetrischen Schlüssel – idealerweise per DHE abgesichert – aus, weil das deutlich performanter ist. Ein Zertifikat wird es für *mich* nur, wenn mein privater Schlüssel durch eine CA bestätigt ist – z.B. bei Webservern üblich – bei SSH habe ich das noch nicht gesehen.
Daher dachte ich, dass der Hinweis auf den public- bzw. private Key im Artikel (mit Verlinkung) hinreichend deutlich macht, wie die Absicherung erfolgt.
Natürlich handelt es sich bei SSH auch um Zertifikate. Nur eben um selbst erstellte, die nicht von einer CA erstellt wurden. Jeder kann diese erstellen. Wichtig ist eben nur, dass man dann darauf achten muss, ob der Server auch der Server ist, wie z.B. hier gut zu sehen:
https://www.howtoforge.de/images/ssh_key_based_logins_putty/6.png
Diese Bezeichnung mag definitorisch stimmen, scheint aber im Web so nicht üblich zu sein (vgl. auch dein Link – key-based !&& cert-based). Daher wohl meine Irritation.
Hallo Maik,
guter Beitrag. Gerade auch interessant für Einsteiger in diesem Bereich.
Solltest du mal auf der Suche nach Hilfe sein, findest du diese bestimmt auf hosttalk – https://www.hosttalk.de/
ein „if ! pgrep …; then auf; fi“ waer eventuell eleganter als das „ps|grep / COUNT“-konstrukt.
(und da hat wordpress was verschluckt … „then bau-tunnel-auf;“)
Mein Beispiel gehört auf jeden Fall auch zur Kategorie Useless use of grep…