1.113.6 – Einrichten von Secure Shell (OpenSSH)

zurück zu Linux Zertifizierungen LPIC
Prüfungskandidaten sollten in der Lage sein, OpenSSH zu installieren und zu konfigurieren. Dieses Lernziel beinhaltet grundlegende Installation und Problemlösung von OpenSSH sowie die Konfiguration von sshd für den automatischen Start beim Booten.

Die wichtigsten Dateien, Bezeichnungen und Anwendungen:

* /etc/hosts.allow
* /etc/hosts.deny
* /etc/nologin
* /etc/ssh/sshd_config
* /etc/ssh_known_hosts
* /etc/sshrc
* sshd
* ssh-keygen

Die Techniken zum Einloggen in einen fremden Rechner mittels telnet und rlogin haben einen großen Nachteil, der in einem lokalen (vertrauenswürdigen) Netz keine große Rolle spielt, im Internet aber fatal sein kann. Bei beiden Protokollen werden alle Übertragungen unverschlüsselt realisiert. Das heißt, daß sowohl die Übertragung von Username und Passwort, als auch die der eigentlichen Sitzung von Lauschern mitgelesen werden kann.

Aus diesem Grund existiert eine sichere Lösung, die sogenannte Secure Shell oder kurz ssh. Dieses Protokoll besteht, genauso wie die beiden anderen oben genannten, aus einem Client-Server Paar. Auf dem Rechner, auf dem man sich sicher einloggen soll, läuft der Server (sshd), der User, der sich dort einloggen will, startet den Client (ssh).

Der Server sshd erlaubt nicht nur das sichere Einloggen, sondern ist auch noch ein Ersatz für rsh, das heißt, er kann auch einfach Befehle ausführen, und er ist auch in der Lage, Dateien sicher über das Netz zu transportieren, wenn der User statt ssh das Programm zum Kopieren (scp) aufruft.

Der sshd Daemon wird in der Regel als Stand-Alone Dienst gestartet, also über ein Init-Script und nicht – wie seine Vorgänger – über inetd. Für jede eingehende Verbindung wird dann ein neuer Prozeß gestartet. Dieser neue Prozeß kümmert sich dann um die Schlüsselübergabe, die Verschlüsselung, Authentifizierung, Kommandoausführung und den Datentransfer.

Jeder Rechner hat einen rechnerspezifischen RSA-Schlüssel (normalerweise 1024 Bit breit) der ihn eindeutig identifiziert. Der Server erstellt zusätzlich in regelmäßigen Abständen einen speziellen Serverschlüssel (meist 768 Bit), der niemals abgespeichert, sondern immer nur im Speicher gehalten wird.

Sobald ein Client eine Anfrage startet, schickt der Server ihm seine beiden Public-Keys (Server und Host Schlüssel). Der Client überprüft dann, ob der Hostschlüssel des Servers mit seinem gespeicherten übereinstimmt und hat so die Gewißheit, daß es sich tatsächlich um den gewünschten Server handelt und nicht um eine Fälschung. Anschließend erzeugt der Client eine Zufallszahl und verschlüsselt sie mit den beiden Schlüsseln des Servers. Diese verschlüsselte Zahl wird an den Server geschickt. Nur dieser Server, der den passenden Secret-Key hat, kann die Zahl wieder entschlüsseln.

Die Zahl wird im weiteren Verlauf benützt, um die gesamte Kommunikation zwischen Client und Server zu verschlüsseln. Da diese Zahl schon verschlüsselt übertragen wurde, ist es auch einem Lauscher nicht möglich, sie zu verwenden um die Kommunikation abzuhören.

Optional kann sshd auch die Mechanismen der r-Befehle benutzen, die auf die Datei ~/.rhosts basieren. Standardmäßig ist dieses Feature aber abgeschaltet, da es die Sicherheit kompomittieren kann.

Konfiguration des Daemons
Der sshd wird über die Datei /etc/ssh/sshd_config konfiguriert. Diese Datei erlaubt alle notwendigen Einstellungen für den Server. Eine genaue Beschreibung aller Direktiven dieser Datei ist in der Handbuchseite sshd_config(5) nachzulesen. Wichtige Einstellungen sind:

Port N
Die Angabe auf welchem Port sshd laufen soll. Normalerweise ist es Port 22.
HostKey Dateiname
Spezifiziert die Datei, in der der Host-Schlüssel des Servers abgelegt ist. Normalerweise ist das die Datei /etc/ssh/ssh_host_key. Diese Datei darf nicht für alle Welt lesbar sein, ansonsten verweigert sich sshd die Datei zu verwenden.
ServerKeyBits Zahl
Hier wird die Breite des Server-Schlüssels angegeben. Normalerweise 768.
KeyRegenerationInterval Zeit
Die Anzahl der Sekunden, nach denen der Server-Schlüssel neu erstellt werden soll. Standardmäßig sollte hier 3600 (eine Stunde) stehen. Steht hier eine 0, so wird der Schlüssel niemals neu erstellt.
PermitRootLogin yes|no
Ist es erlaubt, daß sich der Systemverwalter über ssh einloggen kann?
IgnoreRhosts yes|no
Sollen die Dateien ~/.rhosts und ~/.shosts ignoriert werden?

Sind diese Einstellungen erledigt, so kann der Daemon gestartet werden.

Weitere Sicherheitseinstellungen
Obwohl sshd nicht über inetd gestartet wird, arbeitet er trotzdem mit den TCP-Wrappern. Diese Technik wurde bereits an anderer Stelle detailiert dargestellt. Der Servername für die Steuerung von sshd in den Dateien /etc/hosts.allow und /etc/hosts.deny ist einfach sshd.

Existiert die Datei /etc/nologin, so verweigert sshd jeden Einlogvorgang außer dem von root (sofern root-Eingänge in der Konfigurationsdatei erlaubt waren). Der Inhalt der Datei wird dem Client übermittelt. Ein Systemverwalter kann also diese Datei anlegen und eine kurze Erklärung hineinschreiben, warum der Zugang gerade verboten ist.

Die Dateien /etc/ssh/ssh_known_hosts und $HOME/.ssh/known_hosts enthalten die Public-Keys aller bekannten Rechner. Die globale Datei wird vom Systemverwalter administriert, die userbezogene wird automatisch angelegt und erweitert, sobald der User sich von einem bisher unbekannten Rechner einloggt.

Jede Zeile dieser Dateien enthält die folgenden durch Leerzeichen getrennten Felder:

Hostnamen Bits Exponent Modulus Kommentar

Hostnamen ist eine durch Kommas getrennte Liste von Namen oder Mustern (* und ? dürfen benutzt werden). Jedes Muster wird mit dem vollständigen Hostnamen des Rechners verglichen, der sich anmelden will.

Bits, Exponent und Modulus werden direkt den Host-Schlüsseln entnommen, die in den Dateien /etc/ssh/ssh_host_*_key.pub gespeichert sind. Das optionale Kommentarfeld wird nicht ausgewertet.

Über diesen Mechanismus können Hosts als bekannt (known) definiert werden. Jeder neue Host, wird – sobald er sich eingeloggt hat, als bekannter Host eingetragen. So können Versuche enttarnt werden, wenn ein fremder Rechner vorgibt, ein anderer – bekannter – zu sein.
Der Login-Vorgang
Wenn ein User sich über ssh erfolgreich angemeldet hat, dann erledigt sshd folgende Schritte:

* Wenn es sich um ein terminalbasiertes Login (nicht um eine Kommandoausführung) handelt, dann gibt sshd aus, wann der letzte Login war und zeigt den Inhalt der Datei /etc/motd an. Anschließend wird die Zeit des aktuellen Logins abgespeichert (um beim nächsten wieder sagen zu können, wann der letzte war).
* Wenn die Datei /etc/nologin existiert, wird ihr Inhalt ausgegeben und die Verbindung getrennt (außer bei einem root-Login).
* sshd wechselt zur Benutzerkennung des Users, der sich eingeloggt hat.
* sshd erzeugt eine grundlegende Umgebung (Shellvariablen wie PATH)
* sshd ließt die Datei $HOME/.ssh/environment wenn sie existiert und nimmt die dort gemachten Einstellungen in die Umgebung auf.
* sshd wechselt in das Homeverzeichnis des Users.
* Wenn $HOME/.ssh/rc existiert, wird es abgearbeitet. Ansonsten wird die Datei /etc/ssh/sshrc gesucht und falls gefunden ausgeführt.
* Startet die Shell (oder das angegebene Kommando)

Schlüsselerzeugung mit ssh-keygen
Der Befehl ssh-keygen erzeugt und verwaltet die RSA und DSA Schlüssel für ssh Verbindungen. Normaluser können sich damit einen Schlüssel erzeugen, der Systemverwalter kann auch den Host-Schlüssel damit anlegen.

Diese Schlüssel sind nicht zwingend für den Gebrauch von ssh erforderlich, bestimmte Server verlangen ihn aber.

Es stehen zwei verschiedene Schlüsseltypen zur Verfügung, rsa und dsa. Mit dem Befehl

ssh-keygen -t Typ

wird ein neues Schlüsselpaar angelegt. Speicherort und Name werden beim Anlegen erfragt. Als Typ stehen rsa und dsa zur Auswahl.

Normalerweise wird dieses Programm hauptsächlich vom Init-Script aufgerufen, wenn das erste Mal der SSH-Server oder -Client betrieben wird, um einen Host-Schlüssel zu erzeugen.

Es ist aber auch möglich, über diese Schlüsselpaare eine Authentifizierung zu steuern, so daß ein User beim Einloggen via ssh kein Passwort mehr angeben muß.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert