|
Authentifizierungsmechanismen Eine der Hauptaufgaben eines SSH Servers ist es, Verbindungen zu einem Computersystem zu ermöglichen oder zu verweigern. Wie in Kapitel 3 schon angesprochen wurde, unterstützt SSH zwei grundlegende Arten der Authentifizierung. Die Serverauthentifizierung, bei der die Identitäten der kommunizierenden Computersysteme geprüft werden, und die Benutzerauthentifizierung, bei der der SSH-Server die Identitäten der Benutzer prüft, die sich auf dem System einloggen möchten.
Wenn sich ein SSH-Client das erste Mal zu einem bestimmten SSH-Server verbindet, erscheint eine Meldung, die besagt, dass der SSH-Server unbekannt ist und die Identität nicht zweifelsfrei festgestellt werden kann. Der Benutzer wird aufgefordert, sich zu entscheiden, ob er dem SSH-Server vertrauen möchte oder nicht (siehe Abbildung 5.1). Entscheidet sich der Benutzer dafür, dem Server zu vertrauen, wird der RSA Schlüssel - eine Art digitaler Fingerabdruck - des SSH-Servers in der Datei known_hosts auf dem Clientsystem permanent gespeichert. Nehmen wir an, ein Benutzer besitzt einen Webserver in einem weit entfernten Rechenzentrum, auf dem er eine wertvolle Webapplikation betreibt, deren Quellcode einen sehr hohen Wert für ihn darstellt. Ein potentieller Angreifer könnte davon erfahren haben und will sich nun unbedingt Zugang zu diesem Webserver verschaffen, indem er sich das Passwort des Benutzers beschafft. Durch einige Analyseverfahren hat der Angreifer herausgefunden, dass der Benutzer SSH einsetzt. Er weiß, dass SSH sehr starke Verschlüsselungsverfahren benutzt und dass es dadurch aussichtslos ist, die Kommunikation mitzulesen. Daher entscheidet er sich, einen eigenen modifizierten SSH-Server zu benutzen und die Kommunikation mit Hilfe einer Man-In-The-Middle Attacke bei dem nächsten Verbindungsaufbau gegen seinen modifizierten SSH-Server zu lenken. Nun müsste der Angreifer also nur noch abwarten, bis sich der Benutzer das nächste Mal einloggt und kommt somit in den Besitz der Benutzerkennung und des dazugehörigen Passworts. Das Known-Hosts-Konzept wirkt genau dieser Art von Attacken entgegen, indem bei jedem Verbindungsaufbau zu einer bekannten Adresse geprüft wird, ob es sich auch wirklich um das besagte Computersystem handelt. Kann der Server, zu dem man sich verbinden möchte, nicht den korrekten RSA Schlüssel vorweisen, so verweigert der SSH-Client den Verbindungsaufbau (siehe Abbildung 5.2).
Für die Umsetzung einer möglichst sicheren Benutzerauthentifizierung existieren in SSH zwei grundlegende Konzepte. Zum einen die klassische Authentifizierung durch die Eingabe eines Passwortes und zum anderen eine Umsetzung des stärkeren und besser zu verwaltenem Public-Key-Konzeptes. Authentifizierung mit Passwort Bei der Passwortauthentifizierung wird das Loginpasswort des Benutzers geprüft. Dabei greift SSH auf die Benutzerkennungen des Systems zu, zu dem man sich verbinden möchte. Um also einen Account für SSH einzurichten, ist im Grunde nichts weiter zu tun, als ein Benutzerkonto auf dem jeweiligen Betriebssystem anzulegen. Um die Authentifizierung durch ein Passwort zu erlauben muss man in der Serverkonfiguration den Wert PasswordAuthentication auf yes setzen. Authentifizierung mit Public Key Bei der Authentifizierung mit Hilfe des Public-Key Verfahrens ist es nicht mehr notwendig, dass sich der Benutzer ein Passwort für den entfernten Zugriff auf ein Computersystem merken muss. Vielmehr authentifiziert er sich mit Hilfe einer Schlüsseldatei. Dazu wird ein Schlüsselpaar erzeugt, das sowohl einen privaten als auch einen dazu passenden öffentlichen Schlüssel enthält. Der öffentliche Schlüssel wird auf den Computersystemen hinterlegt, zu denen man sich verbinden möchte. Der private Schlüssel bleibt im Besitz des Benutzers. Während des Authentifizierungsvorgangens wird dann geprüft, ob der Benutzer einen passenden privaten Schlüssel vorzeigen kann. Ist dies nicht der Fall, lehnt der SSH-Server die Verbindung ab. Schlüsselerzeugung Grundvoraussetzung für eine Public-Key Authentifizierung ist, ein individuelles Schlüsselpaar zu erzeugen. Für diesen Zweck ist in der OpenSSH-Suite ein entsprechendes Programm namens ssh-keygen zu finden.
Um nun einen Schlüssel zu erzeugen, gibt man folgendes Kommando in die Befehlskonsole ein.
ssh-keygen -t rsa -b 2048 Die übergebenen Parameter bewirken, dass ssh-keygen ein RSA-Schlüsselpaar mit einer Verschlüsselungsstärke von 2048 Bit erstellt. Die Standardeinstellung für die Erzeugung von Schlüsselpaaren beträgt 1024 Bit. Die maximale Bitanzahl beträgt 4096. ssh-keygen unterstützt zwei verschiedene Verschlüsselungsverfahren: RSA und DSA. Da RSA bis vor kurzem noch durch Patente geschützt wurde, wurde das freie DSA Verfahren entwickelt. Der Nachteil von DSA gegenüber RSA ist jedoch, dass es eine feste Verschlüsselungsstärke von 1024 Bit hat. RSA hingegen ist in dieser Hinsicht flexibel. Nachdem das oben genannte Kommando eingegeben wurde, wird der Benutzer aufgefordert, verschiedene Angaben zur Erstellung des Schlüsselpaares zu tätigen. Beim ersten Schritt muss dem Programm mitgeteilt werden, wo der private Schlüssel hinterlegt werden soll. Die Standardeinstellung ist das .ssh Verzeichnis im Heimatverzeichnes des Benutzers.
Generating public/private rsa key pair. Enter file in which to save the key (/home/nuki/.ssh/id_rsa): Anschließend wird der Benutzer aufgefordert, eine Passphrase für den Schlüssel einzugeben. Diese Passphrase wird bei jeder Benutzung des Schlüssels abgefragt, um einen Mißbrauch der Schlüsseldatei durch Dritte zu verhindern. Um eine Authentifizierung ohne Passworteingabe zu ermöglichen, lässt man diese Passphrase einfach leer und bestätigt ohne weitere Eingaben mit der Entertaste. Dieses Vorgehen ist jedoch potentiell unsicher. Sollte die Schlüsseldatei kompromitiert werden, kann jede beliebige Person diesen Schlüssel verwenden.
Enter passphrase (empty for no passphrase): Enter same passphrase again: Nun wird der Benutzer darüber informiert, wo die Schlüsseldateien abgelegt worden sind und wie sein digitaler Fingerabdruck lautet.
Your identification has been saved in /home/nuki/.ssh/id_rsa. Your public key has been saved in /home/nuki/.ssh/id_rsa.pub. The key fingerprint is: DE:AD:BE:EF:12:34:56:78:90:DE:AD:BE:EF:12:34:56 nuki@nuki-laptop
Nachdem der erste Schritt getan ist und der Schlüssel erfolgreich erzeugt wurde, muss der Benutzer seinen öffentlichen Schlüssel nur noch auf den Computersystemen bekannt machen, zu denen er sich verbinden möchte. Dies geschieht durch einen Eintrag in der authorized_keys Datei, die im Ordner .ssh zu finden ist. Um den Schlüssel nun in dieser Datei einzutragen, gibt man folgendes Kommando ein:
ssh-copy-id -i ~/.ssh/id_rsa.pub nuki@nuki.gotdns.org Das Programm ssh-copy-id verbindet sich nun zu dem entfernten Computersystem - in diesem Fall ,,nuki-desktop`` - und nimmt die erforderliche Eintragung automatisch für den Benutzer ,,nuki`` vor.
SSH Agent Im vorherigen Abschnitt wurde gezeigt, wie komfortabel eine Public-Key-Infrastruktur in SSH eingerichtet werden kann. Meldet man sich nun auf einem entfernten System, welches die Public-Key-Authentifizierung unterstützt, an, so wird die Passphrase der Schlüsseldatei verlangt. Dies kann bei häufiger Benutzung des Schlüssels leider sehr lästig werden. Aus diesem Grund ist in SSH ein sehr nützlicher Dienst vorhanden. Der SSH-Agent. Der SSH-Agent ist eine Art Gedächtnis für die Schlüssel und die dazu gehörigen Passphrasen des Benutzers. Der Benutzer kann seine Schlüsseldateien an den SSH-Agenten übergeben und dieser regelt anschließend die Authentifizierungen an den unterschiedlichen Computersystemen. Bei dieser Übergabe wird der Benutzer einmal aufgefordert, die zum Schlüssel zugehörige Passphrase einzugeben. Anschließend kann der Schlüssel beliebig oft benutzt werden, ohne ein weiteres Mal das Passwort eingeben zu müssen.
Ein Schlüssel wird mit dem Kommando ssh-add Pfad_der_Schlüsseldatei an den SSH-Agenten übergeben. Nach der Eingabe des Passwortes ist der Schlüssel nun im SSH-Agenten gespeichert. Sollte sich der Benutzer nun an einem entfernten Computersystem anmelden wollen, so übernimmt der SSH-Agent die Authentifizierung automatisch. Dieses Vorgehen hat sich vor allem in der Praxis bewehrt, wenn es um automatisierte Administrationsvorgänge geht, da hier meist kein Benutzer vor einem Terminal bereit steht, um die Passwörter der verschiedenen Schlüsseldateien während der Ausführung eines Scriptes einzugeben.
|
|||||||
Stefan Schweiger, Am Spörkel 41, 44227 Dortmund Email: info@ssh-tutorial.de Verantwortlich für den Inhalt gemäß § 10 MDStV: Stefan Schweiger |