Ssh mit Zertifikaten absichern

Zugriff auf Secure Shell mit Schlüsseln sichern

Viele Dinge kann man über das Webinterface der DS erledigen. Doch manchmal muss man mit root Rechten etwas an der Konsole fummeln und da gibt es nur zwei Möglichkeiten des Zugriffs

• telnet (Port 23)
• ssh (Port 22)

telnet ist okay wenn man aus dem LAN auf den Server zugreifen will, denn es ist nicht verschlüsselt und damit werden Login Daten unverschlüsselt übermittelt. Für Zugriffe von ausserhalb des LAN ist es jedoch aus Gründen der Sicherheit nicht zu empfehlen.

Da kommt dann ssh zum Zuge. Dieses Protokoll verlangt eine Verschlüsselung. Auf der DS wird dazu OpenSSH eingesetzt. Der entscheidende Vorteil liegt auf der Hand: Die gesamte Verbindung vom Aufbau bis zum Ende ist durchgehend verschlüsselt. Dabei bietet ssh die klassische Anmeldung mit Username und Passwort, aber auch die Methode via Username und Private Key. Der Vorteil der Private Key Methode ist es, dass es nicht mehr möglich ist mit Passwort auf die DS zuzugreifen und damit laufen alle Brute Force Attacken ins Leere.

Hintergrund

Das Private/Public-Key Verfahren wurde in den späten 50-iger Jahren von Kryptografen des englischen Militärs entwickelt. Durch die damals herrschende Geheimhaltung wurde diese Entwicklung nicht publik und so galten dann die Herrn Diffie und Hellman in den 70-iger Jahren als Entdecker von Public Key. Sie lösten mit "ihrer" Erfindung die zwei grundlegendsten Probleme der Kryptografie:

• Schlüsselverteilungsproblem
• Schlüsselaustauschproblem

Schlüsselaustauschproblem

Das grundlegende Problem hierbei ist: Wie können sich Alice und Bob auf ein Geheimnis einigen (Schlüssel) über ein unsicheres Medium? Ohne dass Carl mit den Informationen etwas anfangen könnte? Dieses Problem bereitete Generationen von Kryptografen schlaflose Nächte. Hellman konzentrierte sich auf dieses Problem und sah folgende Einwegfunktion als optimal an:
Y^x (mod P) = N
Alice und Bob sprechen miteiander erst die Werte für Y (7) und P (11) ab. Diese sind nicht geheim und Carl darf diese kennen. Solange P grösser als Y ist, sind eigentlich alle Zahlen erlaubt.

	Alice	Bob
Stufe 1	wählt einen Wert für x (3) Das ist der geheime Teil	wählt einen Wert für x (6) Das ist der geheime Teil
Stufe 2	73(mod 11)= 343(mod 11)= 2	76(mod 11)= 117649(mod 11)= 4
Stufe 3	Senden des Resultats an Bob	Senden des Resultats an Alice
Austausch	Normalerweise ist das der kritische Moment beim Austausch von sensitiven Informationen. Carl kann die jeweiligen Resultate abfangen. Es ist jedoch gerade der Clou dieser Idee, dass diese Informationen nicht ausreichen, weil sie eben nicht der Schlüssel sind. Carl kann damit überhaupt nichts anfangen, wie wir gleich sehen werden
Stufe 4	wendet Bob's Resultat mit ihrem geheimen x an 43(mod 11)=64(mod 11)=9	wendet Alice's Resultat mit seinem geheimen x an 26(mod 11)=64(mod 11)=9
Schlüssel	Wie durch ein Wunder kommen Alice und Bob auf die gleiche Zahl, ohne diese Information ausgetauscht zu haben!! Das ist der Schlüssel für die sichere Kommunikation zwischen Alice und Bob

Schlüsselverteilungsproblem

Hellman konzentrierte sich auf das Schlüssel-Tausch-Problem (obige Tabelle) und Diffie suchte nach einer völlig neuen Lösung der Schlüssel-Verteilung. Bis anhin war es so, dass die verwendeten Schlüssel der symmetrischen Verschlüsselung physisch überbracht werden mussten. Dazu wurden Kuriere eingesetzt, was natürlich sehr risikoreich war. z.B. mussten Banken tausende von Schlüsseln an Filialen und Kunden ausliefern und diese aus Sicherheitsgründen immer wieder zu erneuern. Wenn einer der Schlüssel kompromitiert wurde, dann mussten wieder neue Schlüssel an die Betroffenen ausgeliefert werden. Eine Übertragung der Schlüssel via Telefon (unsicheres Medium) kam nicht in Frage, da bei symmetrischen Verschlüsselungen der Schlüssel nicht nur zum Ver-sondern auch zum Entschlüsseln gebraucht wird. Carl könnte die Schlüssel sonst mithören und die Kommunikation zwischen Alice und Bob entschlüsseln. Auch könnte er den Kurier, der den Schlüssel von Alice zu Bob bringt, überfallen und ihm den Koffer klauen oder den Schlüssel unbemerkt kopieren!

Und genau hier kommt die volle Eleganz eines Public-Key-Verfahrens zum Tragen. Nicht nur, dass Alice und Bob sich auf einen Schlüssel einigen können ohne diesen austauschen zu müssen, die asymmetrische Methode und ihre zwei Schlüssel sorgt dafür, dass Alice ihren Public Key der ganzen Welt via ein unsicheres Medium (damals Telefon, heute Internet) bekanntmachen kann. Sie muss nicht befürchten, dass jemand mit diesem Schlüssel an sie gerichtete Meldungen entschlüsseln kann Alice und Bob können ihre öffentlichen Schlüssel der ganzen Welt zugänglich machen, damit ihnen diese verschlüsselte Mitteilungen senden können. Dazu werden vorzugsweise öffentliche Key-Server eingesetzt.

Diffie und Hellman lösten damit zwei der grössten Probleme der Kryptografie auf einen Schlag und legten den Grundstein für praktisch alle heute eingesetzten Kryptosysteme. Sie sorgten dafür, dass sich Alice und Bob auf ein Geheimnis einigen können ohne diese Information wirklich zu senden (Schlüssel-Austausch-Problem) und dafür, dass ein Schlüssel völlig risikolos öffentlich zugänglich gemacht werden kann (Schlüssel-Verteilungs-Problem). Die Sicherheit aller bisherigen Kryptosysteme kam an einem oder beiden dieser Probleme an die Grenzen

Vorarbeiten für SSH mit Schlüsseln

Bevor man die Anmeldung mit Schlüsseln und SSH einsetzen kann müssen einige Vorarbeiten erledigt werden. Dazu gehören die Vorabeiten am SSH auf der DS, das Erstellen der Schlüssel und das exportieren der Public Keys auf die DS. Am Schluss empfehle ich dringend noch den telnet Zugang zu aktvieren, falls irgendetwas an der SSH Konfig faul ist besteht sonst kein Zugriff mehr auf die DS.

Vorarbeiten auf der DS

Jeder Benutzer, der sich via Key authentifizieren darf muss bestimmte Dateien und Verzeichnisse in seinem Homeverzeichnis haben. Wie man Homeverzeichnisse erstellt steht im www beschrieben (kommt aber auch mit der nächsten Firmware von Synology) und daher gehe ich darauf nicht weiter ein. Im HOME Verzeichnis des Users muss zuerst ein verstecktes Verzeichnis ssh erstellt und die Rechte sehr restriktiv gesetzt werden

$ mkdir ~/.ssh
$ chmod 0700 ~/.ssh
$ touch ~/.ssh/authorized_keys
$ chown -R EUER_BENUTZER ~/.ssh
$ chmod 0600 ~/authorized_keys

Dabei steht ~/ für das Homeverzeichnis des gerade angemeldeten Benutzers. Dann muss die PubKey Auth in ssh aktiviert werden. Dazu in /etc/ssh/sshd_config das Kommentarzeichen (#) vor den folgenden Direktive entfernen

#PubkeyAuthentication yes
#AuthorizedKeysFile     .ssh/authorized_keys

Schlüssel erstellen

Fehler beim Erstellen des Vorschaubildes: Datei fehlt

Erstellen eines Public-Private Key Pairs

Zum Erstellen der Schlüssel bietet sich ein Tool wie Putty bzw Putty KeyGen an. Dazu startet ihr Putty KeyGen und klickt mit den Standarteinstellungen auf Generate

Fehler beim Erstellen des Vorschaubildes: Datei fehlt

Erstellen eines Public-Private Key Pairs

Nach dem Klick müsst ihr den Mauszeiger eine gewisse Zeit über das Feld fahren lassen, damit genügend Zufallswerte für den Schlüssel entstehen

Fehler beim Erstellen des Vorschaubildes: Datei fehlt

Erstellen eines Public-Private Key Pairs

Am Schluss gebt ihr für den Private Key ein Passwort vor und klickt auf Save PrivateKey. Oben hat Putty netterweise den Eintrag der Public Keys für das authorized_keys-File bereits erstellt. Den Code kann man in die Zwischenablage kopieren und dann in der Datei des jeweiligen Users so rein-pasten. Achtet Euch darauf, dass alles auf einer Zeile (ohne Zeilenumbrüche!!!) steht

Public Key auf der DS eintragen

Zum Schluss muss man jetzt also diesen Public Key String in die authorized_keys Datei des jeweiligen Users bringen. Wenn ihr ihn in der Zwischenablage habt und ein Tool wie Putty benutzt, dann kann man den Inhalt der Zwischenablage mittels eines Rechtsklicks an die Position des Cursors einfügen. Öffnet also die Datei in einem Editor Eurer Wahl (bei mir fast immer nano) und fügt den Inhalt ein

$ nano -w ~/.ssh/authorized_keys
<<Rechtsklick mit der Maus>>
<<ctrl+x für exit und y zum speichern>>

Backup Zugang für alle Fälle

Als Backup Zugang für alle SSH Experimente bietet sich telnet an. Wie man diesen Zugang aktiviert steht hier im Wiki, drum gehe ich nicht näher darauf ein. Der Backup Zugang ist wichtig, 1) weil es sein kann, dass die ssh Verbindung beim Aufrufen des ssh Startscripts abreist und der Dämon dann nicht neugestartet wird und 2) weil eine Fehlkonfig in der sshd_conf oder authorized_keys Datei den Start des SSH Dämons komplett verhindern könnte. Also ist es besser ein telnet-Hintertürchen zu haben, falls was schief geht.