SSH-Server einrichten und betreiben/ Einsatzszenarien/ OpenSSHD mit Public Key

Einleitung

Bei Verwendung von Public Key Verfahren muss zur Anmeldung an einem Server kein Passwort eingegeben werden. Statt dessen legimiert die Existenz eines passenden privaten Schlüssels auf dem eigenen Rechner zum Zugang auf einem anderen Rechner. Obwohl diese Datei kopiert werden kann, um den passwortlosen Zugang von verschiedenen Rechnern zu nutzen, sollte dennoch für jeden Rechner ein eigenes Schlüsselpaar generiert werden, welches diesen Rechner nicht verlässt.

Dieser Zugang muss vorbereitet werden. Zu dem eigenen privaten Schlüssel gehört ein öffentlicher Schlüssel, der an passender Stelle auf dem Server hinterlegt werden muss.

Zielsetzung

In diesem Szenarium wird ein SSH-Server konfiguriert, dass Nutzer per kryptografischen Schlüsseln authentifiziert werden und kein Passwort benötigt wird. Das Verfahren ist prinzipiell sicher genug, dass diese Zugangsform für öffentlich erreichbare Server ausreichend ist.

Für jeden Nutzer wird auf jedem Nutzerkonto eines Servers dieser passwortlose Zugang eingerichtet. Prinzipiell sind folgende Situationen mit Public Key Anmeldung umsetzbar:

• Auf dem SSH-Server wird für jeden Nutzer ein Konto eingerichtet und dessen öffentlicher Schlüssel in seinem eigenen Konto hinterlegt.
• Auf dem SSH-Server wird für einen Administrationskonto öffentliche Schlüssel verschiedener Personen hinterlegt.
• Auf dem SSH-Server wird für ein Nutzerkonto die öffentlichen Schlüssel von verschiedenen Rechnern/Nutzern hinterlegt (beispielsweise bei Github oder GitLab).

Vorbereitung

Wenn noch nicht vorhanden, muss zunächst auf dem eigenen Rechner ein privater (und öffentlicher) Schlüssel erzeugt werden. Der private Schlüssel darf den eigenen Verantwortungsbereich nicht verlassen, also nicht auf unbeaufsichtigten Datenträger gespeichert oder auf ungesicherten Rechner gespeichert.

Zu den Unix-Werkzeugen von OpenSSH gehört das Kommandozeilenprogramm ssh-genkey mit dem die SSH-Schlüssel erstellt und verwaltet werden können. Von SSH werden DSA, RSA und ECDSA Schlüssel akzeptiert. ECDSA ist die Gruppe mit elliptischen Kurven; von diesen wird noch eine Sonderform ed25519 akzeptiert. Die Schlüssellängen für ed25519 und DSA sind fix vorgegeben, während die Schlüssellänge für RSA und ECDSA frei gewählt werden können. Längere Schlüssel bedeuten höhere Sicherheit.

Zum einfachen Erstellen eines Schlüsselpaares dient einer der folgender Befehlen:

ssh-keygen -t ed25519 # Erzeugt ED25519-Schlüssel
ssh-keygen -t dsa # Erzeugt DSA mit einer Schlüssellänge von 1024bits
ssh-keygen -t RSA -b 2048 # Erzeugt ein RSA-Schlüssel mit 2048bits, wobei Schlüssellänge aktuell zwischen 1024 und 16384 liegen darf
ssh-keygen -t ecdsa -b 521 # Erzeugt ECDSA-Schlüssel mit 521bits, wobei die Schlüssellänge 256, 384 oder 521 betragen darf

Mit -t ed25519 wird der Schlüsseltyp festgelegt. Werden keine weiteren Parameter angegeben, werden einige Parameter abgefragt. Zunächst wird der Speicherort definiert. Als Vorgabe werden im Unterverzeichnis .ssh zwei Dateien mit dem Schlüsseltyp als Dateiname verwendet (z.B. /home/user/.ssh/ed25519). Eine Datei wird ohne Endung verwendet (privater Schlüssel), eine Datei wird mit der Endung '.pub' gespeichert (öffentlicher Schlüssel).

Es liegen zwei Dateien vor:

Privater Schlüssel

Dieser hat keine Endung und muss an dem Gerät vor unbefugtem Zugriff geschützt sein.

Öffentlicher Schlüssel

Diese Datei hat die Endung .pub und darf veröffentlicht werden.

Zur Sicherheitsphilosophie im Umgang mit privaten Schlüsseln gibt es umfangreiche Diskussionen, wie mit privaten Schlüsseln zu verfahren ist. Das hier beschriebene Szenarium ist nur als Einstieg in eine sichere Verwendung von SSH über unsicheren Netzwerken zu verstehen. Es gibt andere Methoden, die eine höhere Sicherheit bringen und die bei hochsensiblen Anlagen vorgezogen werden sollten. Daher reicht für den hier genutzten privaten Schlüssel ein mittleres Schutzniveau. Der Schlüssel sollte nur auf einen Rechner verbleiben und vor Zugriff durch andere Nutzer geschützt sein. Sicherheitskopien sollten nicht angelegt werden. Geht der Schlüssel verloren oder wurde von einer anderen Person kopiert, dann ist es sicherer, auf den betroffenen Geräten den zugehörigen öffentlichen Schlüssel zu entfernen und sich einen neuen privaten Schlüssel zu erstellen.

Der private Schlüssel wird über die Dateirechte so gesichert, dass nur der eigene Nutzer lesend zugreifen darf. Ob dieser private Schlüssel zusätzlich mit einem Passwort geschützt wird, liegt im Ermessen jedes Einzelnen. Im Fokus dieses Szenarium steht aber der vereinfachte Zugang zu SSH-Servern im Vergleich zur Passwort-Nutzung, so dass hier auf eine Sicherung des privaten Schlüssel mit einem Passwort verzichtet wird.

Der öffentliche Schlüssel liegt in einer Textform vor. Es gibt auch Anwendungen, wie GitHub, GitLab, BitBucket und andere, die eine Nutzung mittels SSH ermöglichen und den öffentlichen Schlüssel als Text entgegennehmen.

Der öffentliche Schlüssel muss in einer Form auf den SSH-Server gelangen. Häufig ist der frisch installierte SSH-Server mit Passwort-Anmeldung versehen, so dass zu diesem Zeitpunkt dieser Schlüssel per SCP auf den Server kopiert werden kann. Wird eine SD-Karte für einen Kleinstrechner wie Raspberry Pi vorbereitet, kann der eigene öffentliche Schlüssel sofort auf der SD-Karte hinterlegt werden.

Konfiguration

In der Konfigurationsdatei (gewöhnlich unter /etc/ssh/sshd_config) wird neben der Authentifizierung mit Public Key die Authentifizierung mit Passwörtern ausgeschaltet und weitere Schutzmaßnahmen erhöht. Wichtig sind die Parameter PubkeyAuthentication und AuthorizedKeysFile. Beispielhaft dient folgende Konfiguration:

Port 22
ListenAddress 0.0.0.0
PermitRootLogin no
LoginGraceTime 10
MaxAuthTries 2
MaxSession 3
PasswordAuthentication no
PermitEmptyPasswords no
PubkeyAuthentication yes
X11Forwarding no
IgnoreRhosts yes
AllowUsers user
DenyGroups root adm sys www-data
AuthorizedKeysFile .ssh/authorized_keys

Port

Der SSH-Dienst ist auf dem Rechner unter dem Port 22 erreichbar. Dies ist der Standardport, welcher nicht zwingend angegeben werden muss. Ändern auf einen anderen Port erhöht die Sicherheit nicht, da Portscans sofort herausfinden, auf welchem Port ein SSH-Server lauscht.

ListenAddress

Solange der SSH-Server nur über einen Netzwerkanschluss verfügt, bringt es kein Sicherheitsgewinn, den SSH-Server auf eine IP-Adresse bzw. ein Netzwerk zu begrenzen.

PermitRootLogin

Dem Nutzer Root wird generell kein Zugriff über das Netzwerk gestattet. Mittels sudo lassen sich einzelne Administrationsaufgaben einem Administrator zuweisen und sollte bevorzugt genutzt werden.

LoginGraceTime

Die Zeit für eine Anmeldung. Diese Zeit wird auf 10 Sekunden reduziert. Die Authentifizierung mittels Public Key wird durch die Rechner unter sich ausgehandelt, ohne Benutzerinteraktion, so dass prinzipiell auch noch kleinere Zeiten verwendet werden können.

MaxAuthTries

In der Regel sollte der Client direkt den richtigen privaten Schlüssel vorlegen, so dass auch 1 verwendet werden kann.

MaxSessions

Wenn der Server nur von realen Personen administriert wird und keine automatischen Prozesse über SSH zugreifen, kann die Anzahl der parallel laufenden Sessions reduziert werden.

PasswordAuthentication

Die Anmeldung mittels Passwörtern wird ausgeschaltet.

PermitEmptyPassword

Eigentlich unnötig, da Passwörter nicht mehr verwendet werden. Schadet aber nicht und kann evtl. vorhandene unbekannte Sicherheitslücken abfangen.

PubkeyAuthentication

Die Authentifizierung mittels Public Key Schlüssel wird eingeschaltet.

X11Forwarding

SSH-Server im Internet benötigen in der Regel keine Programme, die über eine GUI verfügen, so dass X11-Weiterleitung nicht benötigt wird.

IgnoreRhosts

RHost-Authentifizierung wird ausgeschaltet.

AllowUsers

Nur die hier gelisteten Nutzer haben Zugang per SSH auf diesen Rechner.

DenyGroups

Mitgliedern der hier definierten Gruppen wird der Zugriff auf den Rechner verwehrt. Es muss kontrolliert werden, ob die Nutzer mit Zugangsrechten nicht in diesen Gruppen gelistet sind.

AuthorizedKeysFile

Datei, in der die öffentlichen Schlüssel zu finden sind. Bei relativen Pfadangaben (ohne führenden Schrägstrich) beziehen sich diese auf das Nutzerverzeichnis.

Die Anmeldung mittels Public Key wird mit dem Parameter PubkeyAuthentication eingeschaltet. Der Client kann dann eine Authentifizierung mit einem kryptographischen Schlüssel einleiten. Mit dem Parameter AuthorizedKeysFile wird festgelegt, in welcher Datei die öffentlichen Schlüssel für jeden Nutzer zu finden sind. Als Standard gilt die Datei .ssh/authorized_keys im Heimatverzeichnis jedes Nutzers.

Einrichten

Der Zugang mittels Public Key muss für jedes SSH-Nutzerkonto separat eingerichtet werden.

In der Konfigurationsdatei wird mit dem Schlüsselwort AuthorizedKeysFile festgelegt, wo die Datei mit den öffentlichen Schlüssel zu finden ist. Als Standard wird dies im Nutzerverzeichnis als .ssh/authorized_keys erwartet. In diese Datei werden die entsprechenden öffentlichen Schlüssel in Textform kopiert. Pro Zeile ein eigener Schlüssel. Leerzeilen sind erlaubt.

Liegt der öffentliche Schlüssel von der Nutzerin Alice als alice.pub vor, wird dieser Schlüssel wie folgt für das SSH-Konto Nutzer eingerichtet:

cat alice.pub >> /home/Nutzer/.ssh/authorized_keys

Mit diesem Befehl wird der öffentliche Schlüssel an die Datei angehängt. Es ist auf die entsprechenden Dateirechte zu achten. Diese Datei darf nur vom Nutzer lesbar und veränderbar sein.

In einer Datei können beliebig viele Schlüssel hinterlegt werden. So kann ein Nutzer den Zugang von unterschiedlichen Rechnern (Bürorechner und Heimrechner) nutzen und dessen öffentliche Schlüssel dort hinterlegen.

Für ein Administrationskonto können die Zugangsdaten von verschiedenen Administratoren hinterlegt werden. Diese müssen sich nicht mehr ein gemeinsames Passwort merken. Ändert sich ein öffentlicher Schlüssel, weil ein Administrator einen neuen Rechner erhalten hat, wird sein Schlüssel ausgetauscht, ohne dass für die anderen Administratoren eine Aktion notwendig ist.

Grenzen

Solange im privaten Umfeld nur eine geringe Anzahl an Geräten per SSH verwaltet werden müssen, ist die Nutzung von einfachen Public Key Methoden angebracht.

In folgenden Bereichen kann die Nutzung allerdings gegenüber anderen Methoden aufwendig sein:

• Hohe Anzahl an Geräten, die verwaltet werden müssen.
• Hohe Anzahl an Nutzern, die verschiedene Geräte nutzen müssen.
• Häufiges Ändern des SSH-Schlüssels.