Lustige Portweiterleitungen

Unse­re Schul­home­page besitzt einen eige­nen Log­in­be­reich, für den wir ger­ne auch die Nutzername/Passwortwortkombination nut­zen woll­ten wie für den Schul­ser­ver. Meh­re­re unter­schied­li­che Zugän­ge sind in der Regel nut­zer­un­freund­lich und wer­den kaum akzep­tiert.

Das ver­wen­de­te Joom­la! hat zum Glück eine Rei­he von Authen­ti­fi­zie­rungs­plug­ins, unter ande­rem LDAP, POP3, IMAP oder Kebe­ros. Am ein­fachs­ten geht es über IMAP, d.h. Joom­la! ver­sucht sich mit den Nut­zer­da­ten bei Mail­ser­ver des Schul­ser­vers ein­zu­log­gen und wenn das klappt, legt es einen neu­en Benut­zer­ac­count an, den es zukünf­tig immer extern authen­ti­fi­ziert. Dum­mer­wei­se klapp­te das bei uns nur über eine unver­schlüs­sel­te Ver­bin­dung zuver­läs­sig — also kei­ne sinn­vol­le Opti­on.

Glück­li­cher­wei­se läuft unser Joom­la! auf einem VSer­ver, auf den wir Shell­zu­griff haben. Mit einem linux­ty­pi­schen Ein­zei­ler kann man den Mail­ser­ver­port durch einen ver­schlüs­sel­ten Kanal auf den VSer­ver tun­neln — bei uns:

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

Das sorgt dafür, das der unver­schlüs­sel­te Mail­ser­ver­port 143 auf dem VSer­ver unter der Port­num­mer 1143 erreich­bar ist.

Nor­ma­ler­wei­se wür­de nach die­sem Kom­man­do das Pass­wort des Benut­zer „unpri­vi­le­ged” (der Nut­zer soll­te mög­lichst wenig Rech­te auf dem Ziel­ser­ver haben, wes­halb die Port­num­mer auch grö­ßer als 1024 sein muss) erfragt wer­den. Damit das nicht geschieht, ver­wen­den wir die Authen­ti­fi­zie­rung per Public-Key.

Unser Schul­ser­ver ist nur per VDSL an das Inter­net ange­bun­den und wird ein­mal täg­lich pro­vi­der­sei­tig vom Netz getrennt. Damit wür­de unser Tun­nel zusam­men­bre­chen. Damit das erkannt wird, läuft fol­gen­des Script per cron­job alle fünf Minu­ten:

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

Die Varia­ble COUNT ent­hält die Aus­ga­be der Befehls­pipe zwi­schen den Backticks ‚. Wenn der Tun­nel offen ist, ent­hält die Aus­ga­be zwei Zei­len (den eigent­li­chen Tun­nel­pro­zess und den Such­pro­zess nach „unpri­vi­le­ged”). Wenn das so ist, tut das Script nichts, wenn nicht, star­tet es den Tun­nel ein­fach neu. Das Script muss mit Root­rech­ten lau­fen, da ein Port unter­halb von 1024 lokal ver­wen­det wird.

Auf die­se Wei­se kann man im Prin­zip jeden Dienst lokal auf einen VSer­ver wei­ter­lei­ten, z.B. auf den LDAP der Mus­ter­lö­sung aus Baden-Würt­tem­berg und muss dann kei­ne Klar­text­pass­wör­ter mehr durch die Gegend schi­cken.

Facebook Like

10 Kommentare

  • Klei­ner Tipp: Ich benut­ze pri­vat autossh. Das macht das gan­ze auto­ma­tisch als Dienst.
    http://www.debianadmin.com/autossh-automatically-restart-ssh-sessions-and-tunnels.html

    Ich neh­me an, dass ihr den SSH-Zugang über Zer­ti­fi­ka­te abfrüh­stückt oder?
    Wäre erwäh­nens­wert.

  • Dan­ke für den Tipp mit autossh. Zer­ti­fi­ka­te? Wir nut­zen Public-Key-Authen­ti­fi­zie­rung. Zer­ti­fi­ka­te ken­ne ich in Zusam­men­hang mit SSH jetzt nicht … Aber natür­lich erzwingt der Web­ser­ver stan­dard­mä­ßig https.

    • Genau.
      Es gibt pri­va­te Zer­ti­fi­ka­te (Pri­va­te key) und öffent­li­che (Public Key). D. h. es geht nur mit bei­den.
      Hier zum noch­mals nach­le­sen: https://de.wikipedia.org/wiki/Digitales_Zertifikat

      • Ok. Dann habe ich einen Denk­feh­ler. Bis­her habe ich immer gedacht, dass im SSH-Pro­to­koll zunächst der Ser­ver­key an den Cli­ent über­mit­telt und vor­erst zur Absi­che­rung der Ver­bin­dung genutzt wird (der den in der Regel gepinnt hat und so ggf. Man-in-the-midd­le-Atta­cken erkennt).
        Nach die­sem Hand­shake wird die Authen­ti­fi­zie­rung durch­ge­führt — ent­we­der mit­tels eines asym­me­tri­schen Schlüs­sel­paa­res oder per Creden­ti­als.
        Danach han­deln Ser­ver und Cli­ent einen sym­me­tri­schen Schlüs­sel — idea­ler­wei­se per DHE abge­si­chert — aus, weil das deut­lich per­for­man­ter ist. Ein Zer­ti­fi­kat wird es für *mich* nur, wenn mein pri­va­ter Schlüs­sel durch eine CA bestä­tigt ist — z.B. bei Web­ser­vern üblich — bei SSH habe ich das noch nicht gese­hen.
        Daher dach­te ich, dass der Hin­weis auf den public- bzw. pri­va­te Key im Arti­kel (mit Ver­lin­kung) hin­rei­chend deut­lich macht, wie die Absi­che­rung erfolgt.

  • Hal­lo Maik,

    guter Bei­trag. Gera­de auch inter­es­sant für Ein­stei­ger in die­sem Bereich.
    Soll­test du mal auf der Suche nach Hil­fe sein, fin­dest du die­se bestimmt auf host­talk — https://www.hosttalk.de/

  • gregoa

    ein „if ! pgrep …; then auf; fi” waer even­tu­ell ele­gan­ter als das „ps|grep / COUNT”-konstrukt.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.