Ssh mit Zertifikaten absichern: Unterschied zwischen den Versionen

Aus
Zeile 53: Zeile 53:
<span style="display:block;clear:both;"></span>
<span style="display:block;clear:both;"></span>
==== Mac OS X, Unix ====
==== Mac OS X, Unix ====
Bei unixoiden Betriebssystemen kann man das Kommandozeilenprogramm <code>ssh-keygen</code> zur Schlüsselgenerierung benutzen. Bei Mac OS X dazu das Programm '''Terminal''' ausführen und in der Shell den Befehl eingeben. Das Programm fragt nach dem Speicherort (voreingestellt ist <code>~/.ssh/id_rsa</code>) und einem Passwort. Erzeugt wird ein Schlüsselpaar, wobei der Public Key an der gleichen Stelle wie der Private Key gespeichert wird, aber das Suffix '.pub' erhält.
Bei unixoiden Betriebssystemen kann man das Kommandozeilenprogramm <code>ssh-keygen</code> zur Schlüsselgenerierung benutzen. Bei Mac OS X dazu das Programm '''Terminal''' ausführen und in der Shell den Befehl eingeben. Das Programm fragt nach dem Speicherort (voreingestellt ist <code>~/.ssh/id_rsa</code>) und einem Passwort. Erzeugt wird ein Schlüsselpaar, wobei der Public Key an der gleichen Stelle wie der Private Key gespeichert wird, aber das Suffix ''.pub'' erhält.


=== Public Key auf der DS eintragen ===
=== Public Key auf der DS eintragen ===

Version vom 5. Oktober 2012, 17:36 Uhr

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 außerhalb 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.

Voraussetzungen

  • Zugriff auf die DS mit ssh oder telnet bereits aktiviert
  • Zugriff auf die Shell mit root Rechten und Admin Passwort
  • Umgang mit einem Konsoleneditor (z.B. vi oder nano)

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. Zum Schluss empfehle ich dringend noch den telnet Zugang zu aktivieren, 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 ~/.ssh/authorized_keys

Alternativ kann man auch einfach auf der DS unter dem Benutzer welcher ssh Keys verwenden will ein ssh localhost starten und die nachfolgende Frage nach dem Key mit yes beantworten, dann einfach abbrechen. Dabei wird automatisch das .ssh Verzeichnis mit den korrekten Rechten erzeugt. Das ganze sollte in etwas so aussehen:

$ ssh localhost
The authenticity of host 'localhost (127.0.0.1)' can't be established.
ECDSA key fingerprint is XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.
Password: 

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

Windows

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

Mac OS X, Unix

Bei unixoiden Betriebssystemen kann man das Kommandozeilenprogramm ssh-keygen zur Schlüsselgenerierung benutzen. Bei Mac OS X dazu das Programm Terminal ausführen und in der Shell den Befehl eingeben. Das Programm fragt nach dem Speicherort (voreingestellt ist ~/.ssh/id_rsa) und einem Passwort. Erzeugt wird ein Schlüsselpaar, wobei der Public Key an der gleichen Stelle wie der Private Key gespeichert wird, aber das Suffix .pub erhält.

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.

Testlauf

Zum Testen des Ganzen müsst ihr erstmal den ssh Daemon neustarten. Dazu loggt ihr Euch am Besten via telnet als root mit Admin Passwort auf der DS ein und ruft das entsprechende Startscript des Daemons auf

$ sh /usr/syno/etc.defaults/rc.d/S95sshd.sh restart

Damit sollte der Daemon neugestartet sein und auf Anfragen warten Zum Testen der PubKey Anmeldung verwendet ihr am besten wieder Putty. Erstellt bei Putty und Hostname eine Verbindung in der Art user@IP_DER_DS und BEVOR ihr auf Verbinden klickt stellt ihr noch den Schlüssel für die Verbindung in Putty unter SSH-->Auth. Dort klickt ihr auf Browse und gebt den Pfad zum Privaten Schlüssel an. Wenn das gemacht ist, klickt ihr auf Connect und die Shell sollte den Username aus dem Hostnamen übernehmen. Dann sollte eine Abfrage nach dem Passwort des Private Key kommen. Das ist keine Abfrage der DS sondern von Putty. Das Passwort des Private Key wird natürlich nicht an die DS übermittelt sondern dient nur der lokalen Kontrolle des Schlüssels auf dem Client

Finale Anpassungen

Wenn die Key Authentifizierung geklappt hat, dann sollte man SSH noch dahingehend anpassen, dass der Daemon nur Anmeldungen via Private Key akzeptiert und die normale Anmeldung mit Username und Passwort verweigert. Erst dann sind Brute Force Attacken ausgeschlossen. Dazu müsst ihr in der sshd_config eine weitere Konfig Var setzen und den SSH Daemon nochmals via telnet neustarten

PasswordAuthentication no

Obige Konfig verhindert, dass der SSH Daemon Passworte akzeptiert. Wenn ein Client versucht sich zu ssh zu verbinden ohne einen Schlüssel(also mit Passwort)/oder einen falschen Schlüssel zu haben, dann wird der ssh Daemon das mit einem REJECT beantworten und der ssh Client wird melden, dass keine unterstützten Authentifizierungsmethoden vom Daemon angeboten würden.

Wenn man zu faul ist das Passwort des Private Keys bei der Anmeldung angeben zu müssen, kann man ein Tool wie Paegant (ist beim Putty zip File dabei) benutzen. Dort lädt man den Private Key und gibt zur Authentifizierung des Passwort an. Wenn man jetzt in Putty eine Verbindung auf user@IP_DER_DS öffnet landet man ohne weiteres direkt auf der Shell. Denn Putty arbeitet mit Peagant zusammen und holt sich die Schlüssel von dort. Damit wird es für Putty überflüssig nach dem PW zu fragen, hat Peagant ja bereits gemacht.

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:
Yx (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.

AliceBob
Stufe 1wählt einen Wert für x (3) Das ist der geheime Teilwählt einen Wert für x (6) Das ist der geheime Teil
Stufe 273(mod 11)= 343(mod 11)= 276(mod 11)= 117649(mod 11)= 4
Stufe 3Senden des Resultats an BobSenden des Resultats an Alice
AustauschNormalerweise 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 4wendet 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üsselWie 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

Es gibt in den meisten Büchern zum Thema asymmetrische Verschlüsselung das schöne Beispiel:

Alice lebt im Land Korruptien und will eine Kiste an Bob senden. Sie weiss, dass Eve bei der Post arbeitet und auch dass bei der Post nur Eve's arbeiten. Also muss sie die Kiste resp den Inhalt für Bob schützen können. Also legt sie eine Kette darum und schliesst diese mit einem Schloss zu dem nur sie den Schlüssel hat.
Dann schickt sie die Kiste auf die Reise zu Bob. Der wiederum hängt ein weiteres Schloss an (auch da hat nur er den Schlüssel) und schickt die Kiste wieder zu Alice. Diese entfernt ihr eigenes Schloss und schickt die Kiste wieder zu Bob. Der kann sein Schloss dann entfernen und die Kiste öffnen.

Um im obigen Beispiel zu bleiben haben Diffie-Hellman dafür gesorgt, dass alle Bewohner von Korruptien, die geheime Meldungen austauschen wollen, ihr Schloss öffentlich zugänglich machen können. Dann kann Alice direkt das Schloss von Bob verwenden und der Round-Trip wird vermieden.
Auch dieser Vergleich wird dem Public-Key Verfahren nicht ganz gerecht. Denn um bei einem Vorhängeschloss zum Schlüssel zu kommen (zumindest zu einer Kopie) ist kein grosser Aufwand nötig. Im Public-Key Verfahren wird dieser Weg durch die Verwendung von modularer Arithmetik, Einwegfunktionen und sehr sehr grossen Primzahlen deutlichst erschwert.

Aber wichtig ist auch sich immer vor Augen zu halten, dass es mit Brute-Force Attacken auf den öffentlichen Schlüssel durch Durchprobieren aller Möglichkeiten bei JEDER Schlüssellänge immer irgendwann gelingen wird den Privaten Schlüssel zu "errechnen" (das ist mathematische Gewissheit). Kann sein, dass es jede Sekunde durch einen Zufallstreffer soweit ist. Die Sicherheit bei Public-Key beruht darauf, dass es bis heute als unmöglich gilt, dass die beiden Faktoren eines Produkts aus zwei Primzahlen anders als mit Primfaktorzerlegung gefunden werden können. Und die Zeit die nötig ist zur Faktorisierung der Primfaktoren steigt exponetial zur Schlüssellänge. Sollte es also jemandem gelingen diesen Weg der Faktorisierung zu umgehen (und sei es auch der komplizierteste Algorithmus den die Welt je gesehen hat), dann sind wir verschlüsselungsmässig wieder in der Steinzeit und tauschen Schlüssel wieder persönlich aus.

Im Gegensatz dazu bieten entsprechende symmetrische Verfahren die mathematische Gewissheit, dass sie nicht gebrochen werden können. Denn durch das durchprobieren aller Schlüssel bei solchen Verfahren entstehen mit Sicherheit mehrere sinnvolle Klartexte

Mit dem Originalschlüssel ergibt sich aus der Chiffre etwas komplett anderes als mit einem anderen Schlüssel und der gleichen Chiffe (verschlüsselter Text)

Schlüssel:  P L M O E Z Q K J Z L R T E A V C R C B Y
Klartext:   a t t a c k t h e v a l l e y a t d a w n
Chiffre:    P E F O G J J R N U L C E I Y V V U C X L
 
Jetzt probiert der Kryptoanlytiker folgenden Schlüssel
 
Schlüssel:  M A A K T G Q K J N D R T I F D B H K T S
Klartxt:    d e f e n d t h e h i l l a t s u n s e t
Chiffre:    P E F O G J J R N U L C E I Y V V U C X L

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

Zum Schluss

SSH und authorized_keys sind sehr mächtig. Es gibt z.B. die Möglichkeit den Aufruf eines externen Programms in authorized_keys zu machen. Diese wirddann bei jeder Anmeldung des Benutzers ausgeführt. Das kann sehr sehr hilfreich sein bei Verbindungen anderer Anwendungen, die man via ssh tunneln will. Als Beispiel nenne ich svn: Hier kann man in authorized_keys svn im Tunnel Modus aufrufen. Und so via PrivateKey Auth und ssh auf ein Subversionsystem zugreifen kann, d.h. jedemals wenn der betreffende User authentifiziert wurde wird die SSH Verbindung zum lokalen Subversion Server getunnelt. Die Eleganz dieses Verfahrens zeigt sich bei Subversion sehr deutlich: Man braucht nur einen svn Benutzer für ALLE Zugrffe. Durch den verwendeten Schlüssel wird in authorized_keys festgestellt mit welchen Parametern (v.a. der Subversion Root damit wird der User in diesem Verzeichnis eingesperrt) der svnserve gestartet werden soll. Man kann also damit für jeden Benutzer je nach verwendetem Schlüssel unterschiedliche Aktionen ausführen lassen. Zusätzlich kann man in authorized_keys die Parameter der ssh Verbindung setzen (z.B. no-pty oder no-port-forwarding) und damit die globalen Werte auch der sshd_config überschreiben. So wäre es z.B. auch möglich Backup Jobs immer bei Anmeldung eines bestimmten Benutzers auszuführen

Beispiel svn

An svn lässt sich das Zusammenspiel mit ssh sehr schön zeigen, wie oben erwähnt. So könnte eine authorized_keys ausschauen, um svnserve im Tunnelmodus zu starten:

command="/opt/bin/svnserve -t -r /volume1/svn/repos/private --tunnel-user=svn",no-port-forwarding,no-agent-forwarding,no-pty  ssh-rsa PUBLIC_KEY1_VALUE COMMENT
command="/opt/bin/svnserve -t -r /volume1/svn/repos/public --tunnel-user=svn",no-port-forwarding,no-agent-forwarding,no-pty ssh-rsa PUBLIC_KEY2_VALUE COMMENT

Bei jeder Authentifizierung via ssh wird der Daemon in der dem User gehörenden Datei nach dem passenden Public Key suchen und den entsprechenden Command ausführen. Im obigen Beispiel ist der KEY1 der für private Zugriffe und KEY2 jener für öffentiche Zugriffe. Der Parameter -t ruft svnserve im Tunnelmodus auf und legt mit -r das Chroot Directory für den User fest. Zusätzlich wird über --tunnel-user der lokale Benutzer für den Zugriff auf svn definiert. Der Aufbau ist also sehr einfach:

command="COMMAND PARAMETER[,]PARAMETER[,]PARAMETER",SSH_PARAMETER,SSH_PARAMETER,SSH_PARAMETER KEY_TYPE KEY_VALUE COMMENT