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?

Zunächst muss man in einem Linux­sys­tem als nor­ma­ler Benut­zer (Cli­ent­be­nut­zer) einen pri­va­ten und einen öffent­li­chen Schlüs­sel gene­rie­ren. Das funk­tio­niert über den Befehl:

ssh-key­gen ‑d

Dabei wird ein Pass­wort abge­fragt. Man kann sei­nen pri­va­ten Schlüs­sel zusätz­lich durch ein Pass­wort schüt­zen, d.h. nur der­je­ni­ge, der die­ses Pass­wort besitzt, darf mit die­sem Schlüs­sel ver­schlüs­seln. Möch­te man z.B. via Script vom frem­den Ser­ver Datei­en holen oder schrei­ben (eine typi­schen Anwen­dung),  darf kein Pass­wort ver­ge­ben wer­den und gleich­zei­tig muss der pri­va­te Schlüs­sel gegen unbe­fug­ten Zugriff ver­stärkt gesi­chert werden.

Durch die­sen Befehl ent­ste­hen zwei Datei­en im Home­ver­zeich­nis des gera­de ein­ge­logg­ten Benutzers:

1. /.ssh/id_dsa.pub (öffent­li­cher Schlüssel)
2. /.ssh/id_dsa (pri­va­ter Schlüssel)

Nur der ers­te Schlüs­sel darf ver­teilt wer­den, also das Sys­tem verlassen!

Jetzt muss der öffent­li­che Schlüs­sel auf den Ser­ver gelan­gen., auf den man sich per Key ein­log­gen möchte.

Damit sind die Arbei­ten auf dem Cli­ent abgeschlossen.

Teil 2: Arbei­ten auf dem Server

Man soll­te sich zunächst über­le­gen, unter wel­chen Benut­zer­na­men (Ser­ver­be­nut­zer) man sich auf dem Ser­ver ein­log­gen möch­te. Es ist nicht immer emp­feh­lens­wert, dass das der Root­be­nut­zer ist.

Man loggt sich zunächst auf dem Ser­ver mit dem gewünsch­ten Benut­zer ein und kopiert die Datei id_dsa.pub  vom Cli­ent in das Home­ver­zeich­nis des Ser­ver­be­nut­zers. Danach legt man dort mit

touch $HOME/.ssh/authorized_keys

die Datei „authorized_keys“ an und kopiert mit

cat $HOME/id_dsa.pub » $HOME/.ssh/authorized_keys

den öffent­li­chen Schlüs­sel in die­se Datei. Anschlie­ßend soll­te man auf dem Ser­ver mit

rm $HOME/id_dsa.pub

Die kopier­te Schlüs­sel­da­tei wie­der löschen.

Teil 3: Generalprobe

Man loggt sich jezt als Cli­ent­be­nut­zer auf dem Cli­ent ein. Anschle­ßend über­prüft man durch:

ssh serverbenutzer@server.tld

ob das alles funk­tio­niert. Hat man einen Schlüs­sel ohne Pass­wort erzeugt, soll­te man jetzt auf dem Ser­ver als

ser­ver­be­nut­zer

ein­ge­loggt sein. Das funk­tio­niert nicht, wenn man auf dem Cli­ent als ein ande­rer Benut­zer ein­ge­loggt ist weil da das Schlüs­sel­paar eben nur für einen Nut­zer gilt.