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 akzeptiert.

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 Option.

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 Minuten:

#!/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­pi­pe zwi­schen den Back­ticks ‚. 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 schicken.

Asymmetrische Verschlüsselung mit SSH

Es gibt zwar zu die­sem The­ma vie­le Tuto­ri­als im Netz, jedoch konn­te ich mir bis­her kei­nes so rich­tig merken.

Was kann man damit eigent­lich anstellen?

Nor­ma­ler­wei­se log­ge ich mich in einen Ser­ver mit einem Benut­zer­na­men und einem Pass­wort ein. Der Ser­ver über­prüft dann, ob mein ein­ge­ge­be­ner Benut­zer­na­me zum auf dem Ser­ver gespei­cher­ten Pass­wort (meist ein Hash) passt und gewährt mir im posi­ti­ven Fall dann Zugriff. Das lässt sich eigent­lich ganz gut mit einem Zah­len­schloss an einem Fahr­rad ver­glei­chen: Nur wer die kor­rek­te Kom­bi­na­ti­on kennt, kann die­ses Schloss öff­nen. Bei einem Fahr­rad­schloss kann ich als böser Bube jedoch durch Aus­pro­bie­ren die kor­rek­te Kom­bi­na­ti­on her­aus­fin­den. Das ist ledig­lich eine Fra­ge der Zeit. Je ein­fa­cher mein Pass­wort auf­ge­baut ist (etwa „3333“, des­to wei­ni­ger Zeit wird der Angrei­fer benötigen.

Auf­grund die­ser Pro­ble­ma­tik wur­de im Ser­ver­be­reich die Authen­ti­fi­zie­rung via Schlüs­sel (Key) erfun­den. Das Ver­fah­ren ist eigent­lich sehr pfif­fig: Der Benut­zer gene­riert zunächst ein­mal zwei Schlüs­sel: Einen pri­va­ten und einen öffent­li­chen. Bei der Anmel­dung am Ser­ver geschieht nun folgendes:

Der Benut­zer sen­det sei­nen Benut­zer­na­men, der aber mit mit sei­nem pri­va­ten Schlüs­sel ver­schlüs­selt (unkennt­lich gemacht) ist. Der Ser­ver besitzt den öffent­li­chen Schlüs­sel und den Benut­zer­na­men des Benut­zers. Bei ihm kommt nun eine kryp­ti­sche Zei­chen­ket­te an, die er nur mit dem öffent­li­chen Schlüs­sel wie­der in den Benut­zer­na­men umwan­deln kann. Die öffent­li­che Schlüs­sel muss zu dem pri­va­ten Schlüs­sel pas­sen. Zudem taugt der öffent­li­che Schlüs­sel nur zur Ent­schlüs­se­lung, nicht jedoch zur Verschlüsselung.

Um ganz genau zu sein (Dan­ke Markus…):

Spe­zi­ell bei SSH ist es nun so, dass die asym­me­tri­sche Ver­schlüs­se­lung nach die­sem Ver­fah­ren nur ver­wen­det wird, um einen Schlüs­sel für eine per­for­man­te­re syn­chro­ne Ver­schlüs­se­lung aus­zu­han­deln. Nach dem Hand­shake machen Ser­ver und Cli­ent also „ihr eige­nes Ding“.

Vor­teil:

Nur wer im Besitz des pri­va­ten Schlüs­sels ist, kann sich am Ser­ver anmel­den. Das Aus­pro­bie­ren von Pass­wor­ten ist theo­re­tisch nicht denk­bar (man müss­te die Ver­schlüs­se­lung imi­tie­ren), aber prak­tisch immens schwie­rig und zeitaufwendig.

Ein Bild für die­ses Ver­fah­ren ist z.B. ein Fahr­rad­schloss mit Schlüs­sel. Der pri­va­te Schlüs­sel hängt am Schlüs­sel­bund des Benut­zers. Die Schloss­me­cha­nik selbst ist der öffent­li­che Schlüs­sel und weit auf­wen­di­ger zu imi­tie­ren als etwa eine Zah­len­kom­bi­na­ti­on herauszufinden.

Natür­lich kann man mit dem Ver­fah­ren nicht nur Benut­zer­na­men, son­dern alle mög­li­chen Tex­te ver­schlüs­seln. – z.B. auch E‑Mails. Den öffent­li­chen Schlüs­sel kann man gefahr­los wei­ter­ge­ben, sodass sich den jeder Emp­fän­ger her­un­ter­la­den kann.

Hier ein­mal ein ein­fa­ches Schaubild:

Wie funk­tio­niert das nun praktisch?

Wei­ter­le­sen