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

Friendly fire

Friend­ly Fire (engl. befreun­de­ter Beschuss) bzw. Freund­be­schuss ist ein euphe­mis­ti­scher Aus­druck aus dem US-ame­ri­ka­ni­schen Mili­tär­jar­gon, der den irr­tüm­li­chen Beschuss eige­ner oder ver­bün­de­ter Streit­kräf­te in einer krie­ge­ri­schen Aus­ein­an­der­set­zung bezeich­net. (Wiki­pe­dia)

… dabei klingt die ver­meint­lich direk­te Über­set­zung so hübsch. Ich hal­te „friend­ly fire“ für die Ursa­che Num­mer 1, war­um Hob­by-Admins so oft an ihren Auf­ga­ben ver­zwei­feln. Aber wel­che Art des Beschus­ses gibt es denn in die­sem Aufgabenfeld?

An den Schu­len in Deutsch­land enga­gie­ren sich unzäh­li­ge Leh­rer- und Leh­re­rin­nen für ihre Schu­le (eigent­lich ihren Schul­trä­ger, der das eigent­lich bezah­len müss­te), um das Schul­netz für Kol­le­gin­nen und Kol­le­gen am Lau­fen zu hal­ten. Ich wür­de vor allem letzt­ge­nann­te Per­so­nen­grup­pe ein­mal als Ana­lo­gie zu den „eige­nen bzw. ver­bün­de­ten Streit­kräf­ten“ sehen. „Beschuss“ kommt nach mei­ner Wahr­neh­mung prin­zi­pi­ell aus die­ser Rich­tung, weil z.B.

  1. nichts wie zu Hau­se ist
  2. die eigens ange­schaff­te Lern­soft­ware mit dem Netz nicht will (nicht dass man den Admin vor­her gefragt hät­te, ob das ginge)
  3. Open­Of­fice benutzt wer­den muss, wo doch zu Hau­se das Paket von Klein­weich läuft
  4. das Netz wegen der Eigen­ad­mi­nis­tra­ti­on doch auch ein­mal, wenn auch sel­ten ausfällt
  5. alles sowie­so viel zu lang­sam geht – das ADmin macht ja schließ­lich nichts „Sicht­ba­res“ (muss even­tu­ell an dem Prin­zip von Rechnern/Software liegen)

Schü­ler soll man ja immer loben und bestä­ti­gen, damit sie ori­en­tiert sind. Für den Admin bleibt da oft nix mehr nach mit dem Lob – allein „friend­ly fire“ schwelt immer wie­der vor sich hin – dum­mer­wei­se nicht aus­schließ­lich im Hin­blick auf die Sphä­re der Admins (so man­che Schul­lei­tung, man­cher A14er wird da auch ein Lied von sin­gen kön­nen) – aber das ist eine ganz ande­re Geschichte.

Professionell, redundant, 98% Verfügbarkeit

Die­se drei Schlag­wor­te sind mir gera­de bei einem Anbie­ter ins Gesicht gesprun­gen. Das letz­te passt für mich nicht zu den bei­den ande­ren in die­sem Tri­ko­lon. Es wird im Netz ja an allen Orten mit die­sen Ver­füg­bar­kei­ten gewor­ben. Was bedeu­tet eigent­lich „98%“ Verfügbarkeit?

Ein Jahr besitzt 365 Tage. 1% Aus­fall bedeu­tet, dass an genau 3,65 Tagen die Ser­vices die­ses Anbie­ters nicht zur Ver­fü­gung ste­hen dür­fen, ohne dass eine Ver­trags­ver­let­zung sei­tens des Anbie­ters vor­liegt. Im vor­lie­gen­den Fall dürf­ten die Leis­tun­gen also theo­re­tisch für einen Zeit­raum von 7,3 Tagen/Jahr kom­plett aus­fal­len – nicht unbe­dingt am Stück, aber ins­ge­samt. Ein sol­ches Niveau erreicht jeder ernst­haf­te und enga­gier­te Hob­by­pro­vi­der. Im B2B-Bereich dürf­te das abso­lut indis­ku­ta­bel sein… Hier sind Ver­füg­bar­kei­ten von 99,7% marktüblich.

Der Anbie­ter könn­te ein­wen­den, dass es sich nur um eine mög­li­che Absi­che­rung für den unver­schul­de­ten Ernst­fall han­delt und die tat­säch­li­che Aus­fall­si­cher­heit erheb­lich höher lie­gen wird. Wenn aber eine Dienst­lei­tung als „pro­fes­sio­nell“ ver­kauft wird und pro­fes­sio­nel­le Prei­se ver­langt wer­den, habe ich als Kun­de auch ein Recht auf eine pro­fes­sio­nel­le Leis­tung, die sich der Anbie­ter zumin­dest in Bezug auf die Ver­füg­bar­keit offen­bar nicht zutraut…

Sowas regelt aber zum Glück der Markt. Und viel­leicht hat der Anbie­ter ja genau die Nische ent­deckt, die ihm die­se für ihn kom­for­ta­ble Rege­lung im Hoch­preis­seg­ment (vier­stel­li­ge Jah­res­bei­tra­ge wer­den ver­langt) erlaubt. Und viel­leicht kommt es bei der ver­kauf­ten Leis­tung ja auch gar nicht auf eine hohe Ver­füg­bar­beit an, sodass ich dem Anbie­ter Unrecht tue.

LDAP: Schulfotoseitenzugriff auf Schulöffentlichkeit beschränken

Bil­der von Schü­le­rin­nen und Schü­lern sind oft ein Pro­blem – vor allem dann, wenn man sie ver­öf­fent­lich und das viel­leicht sogar noch so tut, dass Namen einem bestimm­ten Foto zuge­ord­net wer­den kön­nen. In eini­gen Bun­des­län­dern ist das sogar strikt verboten.

Auch hier kann LDAP abmil­dern: Man nutzt ein Schul-LDAP als „Zapf­stel­le“ für eine HTTP-basier­te Authen­ti­fi­zie­rung, die vie­len bestimmt bekannt ist (.htac­cess).

Mit mei­nem Lieb­lings­web­ser­ver (ligh­ty) geht das sehr leicht – das auth-Modul muss aller­dings akti­viert sein.

server.modules                += ( „mod_auth“ )

auth.backend                 = „ldap“

auth.backend.ldap.hostname   = „127.0.0.1“
auth.backend.ldap.base-dn    = „ou=ldapbaum,dc=foo,dc=tld“
auth.backend.ldap.filter     = „(uid=$)“

$HTTP[„host“] == „subdomain.fuer.fotos“ {
auth.require = (   „“ => (
„method“  => „basic“,
„realm“   => „Anmel­dung bit­te mit Schulo­gin und ‑pass­wort fuer die Seite „,
„requi­re“ => „valid-user“
)
)
}

… und schon ist nach einem /etc/init.d/lighttpd for­ce-rel­oad der Zugriff auf die Sei­te http://subdomain.fuer.fotos mit allen Unter­sei­ten nicht mehr ohne Anmel­dung mög­lich, wenn lokal der LDAP-Ser­ver oder eine Kopie bzw. Repli­ka­ti­on davon mit­läuft. So kann sich der der poten­ti­el­le Kin­der­schän­der nicht mehr ohne Wei­te­res sein nächs­tes Opfer anhand des letz­ten Schwimm­wett­be­werbs­bil­des aus­wäh­len – es sei denn, er kommt selbst von der Schu­le (zuge­ge­be­ner­ma­ßen eine sehr düs­te­re Opti­on). Inge­samt nett und simpel.

Wenn man das jetzt noch mit Web­DAV und Mood­le kom­bi­niert, kann man sogar ein­zel­nen Lehr­kräf­ten Schreib­rech­te in bestimm­ten Mood­le­ord­nern ein­räu­men. Da Ligh­ty regu­lä­re Aus­drü­cke unter­stützt, müss­te das sogar recht schmerz­frei gehen. Aber das ist eine ande­re Geschichte…

Moodle und Benutzerverwaltung…

… ist in mei­nen Augen so gar nicht gelun­gen, da immer wie­der glei­che Pro­ble­me auftreten:

  1. Mood­le akt­zep­tiert z.B. nur Daten­sät­ze, die eine – im For­mat gül­ti­ge E‑Mailadresse – ent­hal­ten. Nun besitzt nicht jeder Schü­ler oder jede Schü­le­rin eine sol­che – von Lehr­kräf­ten ein­mal ganz zu schwei­gen. Das führt oft dazu, dass die Admins „Fan­ta­sie­adres­sen“ erfin­den – im aller­schlimms­ten Fall mit einem gül­ti­gen Domai­n­an­teil – womit man mit sei­ner Ser­ver-IP schnell auf gän­gi­gen Black­lists lan­det und dann kaum Mails mehr ver­schickt wer­den können.
  2. Mood­le loggt exzes­siv Benut­zer­ak­ti­vi­tä­ten (eigent­lich jeden Klick) – das Bewusst­sein für Daten­schutz scheint mir gera­de in anglo­ame­ri­ka­ni­schen Kon­tex­ten nicht so sen­si­bel ent­wi­ckelt. In Deu­sch­land gilt der Grund­satz der Daten­spar­sam­keit. Man kann recht­li­chen Pro­ble­men vor­beu­gen, indem man die Eltern ent­spre­chen­de Ein­ver­ständ­nis­er­klä­run­gen unter­schrei­ben lässt, was einen erheb­li­chen Auf­wand bedeu­tet. Die Anzei­ge einer Infor­ma­ti­on vor der erst­ma­li­gen Anmel­dung, wel­che Daten in wel­chem Umfang erho­ben wer­den, dürf­te bei Min­der­jäh­ri­gen recht­lich ins Lee­re lau­fen. Die­ses Pro­blem wird immer wie­der ger­ne weg­dis­ku­tiert mit dem Argu­ment, dass man sich zwi­schen dem päd­ago­gisch Sinn­vol­len und der Gän­ge­lung durch recht­li­che Kon­tex­te krea­tiv bewe­gen muss. Fakt ist aber lei­der, dass Mood­le nicht das Prin­zip der Daten­spar­sam­keit erfüllt.
  3. Inter­ope­ra­bi­li­tät zwi­schen ver­schie­de­nen Mood­le­sys­te­men (und dadurch zwi­schen Schu­len) wird durch MNET – das Mood­le­net­work mög­lich. Ich war bis­her immer ent­schie­den zu doof, das zu kon­fi­gu­rie­ren. Außer­dem ist mir nie ganz klar­ge­wor­den, wel­che Daten da tat­säch­lich aus­ge­tauscht werden.

Es folgt eine klei­ne Spin­ne­rei, wie der­ar­ti­ge Pro­ble­me tech­nisch gut in den Griff zu bekom­men sind. Das erfor­dert jedoch eini­ges an Brain 2.0 – denn die Lösung heißt in mei­nen Augen LDAP. Wei­ter­le­sen

1 20 21 22 23