So konfigurieren Sie die schlüsselbasierte SSH-Authentifizierung auf einem Linux-Server

Einführung

SSH, oder Secure Shell, ist ein verschlüsseltes Protokoll, das zur Verwaltung und Kommunikation mit Servern verwendet wird. Wenn Sie mit einem Linux-Server arbeiten, werden Sie oft einen Großteil Ihrer Zeit in einer Terminal-Sitzung verbringen, die über SSH mit Ihrem Server verbunden ist.

Es gibt zwar verschiedene Möglichkeiten, sich bei einem SSH-Server anzumelden, aber in dieser Anleitung konzentrieren wir uns auf das Einrichten von SSH-Schlüsseln. SSH-Schlüssel bieten eine extrem sichere Möglichkeit, sich bei Ihrem Server anzumelden. Aus diesem Grund ist dies die Methode, die wir für alle Benutzer empfehlen.

Wie funktionieren SSH-Schlüssel?

Ein SSH-Server kann Clients mit einer Vielzahl von verschiedenen Methoden authentifizieren. Die grundlegendste davon ist die Passwort-Authentifizierung, die einfach zu verwenden, aber nicht die sicherste ist.

Obwohl Passwörter auf sichere Weise an den Server gesendet werden, sind sie im Allgemeinen nicht komplex oder lang genug, um wiederholten, hartnäckigen Angreifern zu widerstehen. Moderne Rechenleistung in Kombination mit automatisierten Skripten machen das Brute-Forcing eines passwortgeschützten Kontos sehr gut möglich. Obwohl es andere Methoden gibt, um zusätzliche Sicherheit hinzuzufügen (fail2ban, etc.), erweisen sich SSH-Schlüssel als zuverlässige und sichere Alternative.

SSH-Schlüsselpaare sind zwei kryptografisch sichere Schlüssel, die zur Authentifizierung eines Clients gegenüber einem SSH-Server verwendet werden können. Jedes Schlüsselpaar besteht aus einem öffentlichen Schlüssel und einem privaten Schlüssel.

Der private Schlüssel wird vom Client aufbewahrt und sollte absolut geheim gehalten werden. Eine Kompromittierung des privaten Schlüssels ermöglicht es dem Angreifer, sich ohne zusätzliche Authentifizierung bei Servern anzumelden, die mit dem zugehörigen öffentlichen Schlüssel konfiguriert sind. Als zusätzliche Vorsichtsmaßnahme kann der Schlüssel auf der Festplatte mit einer Passphrase verschlüsselt werden.

Der zugehörige öffentliche Schlüssel kann frei und ohne negative Folgen weitergegeben werden. Der öffentliche Schlüssel kann zum Verschlüsseln von Nachrichten verwendet werden, die nur der private Schlüssel entschlüsseln kann. Diese Eigenschaft wird für die Authentifizierung mit dem Schlüsselpaar genutzt.

Der öffentliche Schlüssel wird auf einen entfernten Server hochgeladen, bei dem man sich mit SSH anmelden möchte. Der Schlüssel wird zu einer speziellen Datei innerhalb des Benutzerkontos hinzugefügt, bei dem Sie sich anmelden werden, und zwar ~/.ssh/authorized_keys.

Wenn ein Client versucht, sich mit SSH-Schlüsseln zu authentifizieren, kann der Server den Client daraufhin testen, ob er im Besitz des privaten Schlüssels ist. Wenn der Client nachweisen kann, dass er im Besitz des privaten Schlüssels ist, wird eine Shell-Sitzung erzeugt oder der angeforderte Befehl ausgeführt.

Schritt 1 – Erstellen von SSH-Schlüsseln

Der erste Schritt zur Konfiguration der SSH-Schlüsselauthentifizierung gegenüber Ihrem Server besteht darin, ein SSH-Schlüsselpaar auf Ihrem lokalen Computer zu erzeugen.

Dazu können wir ein spezielles Dienstprogramm namens ssh-keygen verwenden, das in der Standard-OpenSSH-Suite von Tools enthalten ist. Standardmäßig wird damit ein 3072-Bit-RSA-Schlüsselpaar erzeugt.

Erzeugen Sie auf Ihrem lokalen Computer ein SSH-Schlüsselpaar, indem Sie Folgendes eingeben:

ssh-keygen
Output
 Generating public/private rsa key pair.
 Enter file in which to save the key (/home/username/.ssh/id_rsa):

Das Dienstprogramm fordert Sie auf, einen Speicherort für die zu erzeugenden Schlüssel auszuwählen. Standardmäßig werden die Schlüssel im Verzeichnis ~/.ssh im Home-Verzeichnis Ihres Benutzers gespeichert. Der private Schlüssel wird id_rsa und der zugehörige öffentliche Schlüssel id_rsa.pub genannt.

In der Regel ist es am besten, an dieser Stelle beim Standardspeicherort zu bleiben. Auf diese Weise kann Ihr SSH-Client Ihre SSH-Schlüssel automatisch finden, wenn Sie versuchen, sich zu authentifizieren. Wenn Sie einen anderen als den Standardpfad wählen möchten, geben Sie diesen jetzt ein, andernfalls drücken Sie ENTER, um die Vorgabe zu übernehmen.

Wenn Sie zuvor ein SSH-Schlüsselpaar erzeugt haben, sehen Sie möglicherweise eine Eingabeaufforderung, die wie folgt aussieht:

Output
 /home/username/.ssh/id_rsa already exists.
 Overwrite (y/n)?

Wenn Sie sich für das Überschreiben des Schlüssels auf der Festplatte entscheiden, können Sie sich nicht mehr mit dem vorherigen Schlüssel authentifizieren. Seien Sie sehr vorsichtig, wenn Sie Ja wählen, da dies ein zerstörerischer Vorgang ist, der nicht rückgängig gemacht werden kann.

Output
 Created directory '/home/username/.ssh'.
 Enter passphrase (empty for no passphrase):
 Enter same passphrase again:

Als nächstes werden Sie aufgefordert, eine Passphrase für den Schlüssel einzugeben. Dies ist eine optionale Passphrase, die zum Verschlüsseln der privaten Schlüsseldatei auf der Festplatte verwendet werden kann.

Sie fragen sich vielleicht, welche Vorteile ein SSH-Schlüssel bietet, wenn Sie trotzdem eine Passphrase eingeben müssen. Einige der Vorteile sind:

Der private SSH-Schlüssel (der Teil, der mit einer Passphrase geschützt werden kann), wird niemals im Netzwerk offengelegt. Die Passphrase wird nur zum Entschlüsseln des Schlüssels auf dem lokalen Rechner verwendet. Dies bedeutet, dass netzwerkbasiertes Brute-Forcing gegen die Passphrase nicht möglich ist.

Der private Schlüssel wird in einem eingeschränkten Verzeichnis aufbewahrt. Der SSH-Client erkennt keine privaten Schlüssel, die nicht in eingeschränkten Verzeichnissen aufbewahrt werden. Der Schlüssel selbst muss ebenfalls eingeschränkte Berechtigungen haben (Lese- und Schreibrechte nur für den Besitzer). Das bedeutet, dass andere Benutzer auf dem System nicht schnüffeln können.

Jeder Angreifer, der die Passphrase des privaten SSH-Schlüssels knacken will, muss bereits Zugriff auf das System haben. Das bedeutet, dass sie bereits Zugriff auf Ihr Benutzerkonto oder das Root-Konto haben werden. Wenn Sie sich in dieser Position befinden, kann die Passphrase den Angreifer daran hindern, sich sofort bei Ihren anderen Servern anzumelden. Dies gibt Ihnen hoffentlich Zeit, ein neues SSH-Schlüsselpaar zu erstellen und zu implementieren und den Zugriff des kompromittierten Schlüssels zu entfernen.

Da der private Schlüssel niemals dem Netzwerk ausgesetzt wird und durch Dateirechte geschützt ist, sollte diese Datei niemals für jemand anderen als Sie (und den Root-Benutzer) zugänglich sein. Die Passphrase dient als zusätzliche Schutzebene für den Fall, dass diese Bedingungen gefährdet sind.

Eine Passphrase ist ein optionaler Zusatz. Wenn Sie eine eingeben, müssen Sie sie jedes Mal angeben, wenn Sie diesen Schlüssel verwenden (es sei denn, Sie verwenden eine SSH-Agentensoftware, die den entschlüsselten Schlüssel speichert). Wir empfehlen die Verwendung einer Passphrase, aber wenn Sie keine Passphrase festlegen möchten, können Sie ENTER drücken, um diese Aufforderung zu umgehen.

Output
 Your identification has been saved in /home/username/.ssh/id_rsa.
 Your public key has been saved in /home/username/.ssh/id_rsa.pub.
 The key fingerprint is:
 SHA256:CAjsV9M/tt5skazroTc1ZRGCBz+kGtYUIPhRvvZJYBs [email protected]
 The key's randomart image is:
 +---[RSA 3072]----+
 |o   ..oo.++o ..  |
 | o o +o.o.+…   |
 |. . + oE.o.o  .    |
 | . . oo.B+  .o    |
 |  .   .=S.+ +     |
 |      . o..*          |
 |        .+= o      |
 |        .=.+         |
 |       .oo+         |
 +----[SHA256]-----+

Sie haben nun einen öffentlichen und einen privaten Schlüssel, die Sie zur Authentifizierung verwenden können. Der nächste Schritt besteht darin, den öffentlichen Schlüssel auf Ihrem Server zu platzieren, damit Sie sich mit der SSH-Schlüsselauthentifizierung anmelden können.

Schritt 2 – Kopieren eines öffentlichen SSH-Schlüssels auf Ihren Server

Es gibt mehrere Möglichkeiten, Ihren öffentlichen Schlüssel auf Ihren entfernten SSH-Server hochzuladen. Welche Methode Sie verwenden, hängt weitgehend von den verfügbaren Tools und den Details Ihrer aktuellen Konfiguration ab.

Die folgenden Methoden führen alle zum gleichen Endergebnis. Die einfachste, am stärksten automatisierte Methode wird zuerst beschrieben, und die darauf folgenden erfordern jeweils zusätzliche manuelle Schritte. Sie sollten diese nur anwenden, wenn Sie die vorangegangenen Methoden nicht verwenden können.

Kopieren Ihres öffentlichen Schlüssels mit ssh-copy-id

Die einfachste Methode, Ihren öffentlichen Schlüssel auf einen vorhandenen Server zu kopieren, ist die Verwendung eines Dienstprogramms namens ssh-copy-id. Wegen seiner Einfachheit wird diese Methode empfohlen, wenn sie verfügbar ist.

Das Tool ssh-copy-id ist in vielen Distributionen in den OpenSSH-Paketen enthalten, so dass Sie es möglicherweise bereits auf Ihrem lokalen System zur Verfügung haben. Damit diese Methode funktioniert, müssen Sie derzeit über einen passwortbasierten SSH-Zugang zu Ihrem Server verfügen.

Um das Dienstprogramm zu verwenden, müssen Sie den Remote-Host angeben, zu dem Sie eine Verbindung herstellen möchten, sowie das Benutzerkonto, auf das Sie passwortbasierten SSH-Zugriff haben. Dies ist das Konto, in das Ihr öffentlicher SSH-Schlüssel kopiert werden soll.

Die Syntax lautet:

ssh-copy-id [email protected]_host

Sie sehen möglicherweise eine Meldung wie diese:

Output
 The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established.
 ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
 Are you sure you want to continue connecting (yes/no)? yes

Dies bedeutet, dass Ihr lokaler Computer den Remote-Host nicht erkennt. Dies geschieht, wenn Sie zum ersten Mal eine Verbindung zu einem neuen Host herstellen. Geben Sie yes ein und drücken Sie ENTER, um fortzufahren.

Als nächstes durchsucht das Dienstprogramm Ihr lokales Konto nach dem Schlüssel id_rsa.pub, den wir zuvor erstellt haben. Wenn es den Schlüssel findet, fordert es Sie zur Eingabe des Passworts für das Konto des Remote-Benutzers auf:

Output
 /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
 /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
 [email protected]'s password:

Geben Sie das Kennwort ein (Ihre Eingabe wird aus Sicherheitsgründen nicht angezeigt) und drücken Sie ENTER. Das Dienstprogramm verbindet sich mit dem Konto auf dem entfernten Host unter Verwendung des von Ihnen angegebenen Passworts. Es kopiert dann den Inhalt Ihres Schlüssels ~/.ssh/id_rsa.pub in eine Datei im Home-Verzeichnis ~/.ssh des entfernten Kontos namens authorized_keys.

Sie werden eine Ausgabe sehen, die wie folgt aussieht:

Output
 Number of key(s) added: 1
 Now try logging into the machine, with:   "ssh '[email protected]'"
 and check to make sure that only the key(s) you wanted were added.

An diesem Punkt wurde Ihr Schlüssel id_rsa.pub auf das Remote-Konto hochgeladen. Sie können mit dem nächsten Abschnitt fortfahren.

Kopieren Ihres öffentlichen Schlüssels mit SSH

Wenn Sie ssh-copy-id nicht zur Verfügung haben, aber über einen passwortbasierten SSH-Zugang zu einem Konto auf Ihrem Server verfügen, können Sie Ihre Schlüssel mit einer herkömmlichen SSH-Methode hochladen.

Wir können dies tun, indem wir den Inhalt unseres öffentlichen SSH-Schlüssels auf unserem lokalen Computer ausgeben und ihn über eine SSH-Verbindung an den entfernten Server leiten. Auf der anderen Seite können wir sicherstellen, dass das Verzeichnis ~/.ssh unter dem von uns verwendeten Konto existiert, und dann den Inhalt, den wir über die Pipeline geleitet haben, in eine Datei namens authorized_keys innerhalb dieses Verzeichnisses ausgeben.

Wir werden das Umleitungssymbol >> verwenden, um den Inhalt anzuhängen, anstatt ihn zu überschreiben. So können wir Schlüssel hinzufügen, ohne zuvor hinzugefügte Schlüssel zu zerstören.

Der vollständige Befehl sieht wie folgt aus:

cat ~/.ssh/id_rsa.pub | ssh [email protected]_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Sie sehen möglicherweise eine Meldung wie diese:

Output
 The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established.
 ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
 Are you sure you want to continue connecting (yes/no)? yes

Dies bedeutet, dass Ihr lokaler Computer den Remote-Host nicht erkennt. Dies geschieht, wenn Sie zum ersten Mal eine Verbindung zu einem neuen Host herstellen. Geben Sie Ja ein und drücken Sie ENTER, um fortzufahren.

Danach werden Sie aufgefordert, das Kennwort des Kontos einzugeben, mit dem Sie versuchen, eine Verbindung herzustellen:

Output
 [email protected]'s password:

Nach Eingabe Ihres Passworts wird der Inhalt Ihres Schlüssels id_rsa.pub an das Ende der Datei authorized_keys des Kontos des entfernten Benutzers kopiert. Fahren Sie mit dem nächsten Abschnitt fort, wenn dies erfolgreich war.

Manuelles Kopieren Ihres öffentlichen Schlüssels

Wenn Sie keinen passwortbasierten SSH-Zugang zu Ihrem Server zur Verfügung haben, müssen Sie den obigen Vorgang manuell durchführen.

Der Inhalt Ihrer Datei id_rsa.pub muss irgendwie zu einer Datei unter ~/.ssh/authorized_keys auf Ihrem entfernten Rechner hinzugefügt werden. Um den Inhalt Ihres id_rsa.pub-Schlüssels anzuzeigen, geben Sie dies auf Ihrem lokalen Computer ein:

cat ~/.ssh/id_rsa.pub

Sie sehen den Inhalt des Schlüssels, der etwa so aussehen kann:

~/.ssh/id_rsa.pub

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44+tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q+bqgZ8SeeM8wzytsY+dVGcBxF6N4JS+zVk5eMcV385gG3Y6ON3EG112n6d+SMXY0OEBIcO6x+PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B+ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G/12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE+ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77+xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X/vh2xPff6SQ1BL/zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi/uS66+PujOO+xt/2FWYepz6ZlN70bRly57Q06J+ZJoc9FfBCbCyYH7U/ASsmY095ywPsBo1XQ9PqhnN1/YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8/lERo9oxRm5JFX6TCmj6kmiFqv+Ow9gI0x8GvaQ== [email protected]

Greifen Sie auf Ihren Remote-Host mit einer beliebigen Methode zu, die Ihnen zur Verfügung steht. Dies kann eine webbasierte Konsole sein, die von Ihrem Infrastrukturanbieter bereitgestellt wird.

Sobald Sie Zugriff auf Ihr Konto auf dem Remote-Server haben, sollten Sie sicherstellen, dass das Verzeichnis ~/.ssh erstellt wird. Dieser Befehl erstellt das Verzeichnis, falls erforderlich, oder tut nichts, wenn es bereits vorhanden ist:

mkdir -p ~/.ssh

Nun können Sie die authorized_keys-Datei in diesem Verzeichnis erstellen oder ändern. Sie können den Inhalt Ihrer Datei “id_rsa.pub” an das Ende der Datei “authorized_keys” anfügen und sie gegebenenfalls wie folgt erstellen:

echo public_key_string >> ~/.ssh/authorized_keys

Ersetzen Sie im obigen Befehl den public_key_string durch die Ausgabe des Befehls cat ~/.ssh/id_rsa.pub, den Sie auf Ihrem lokalen System ausgeführt haben. Sie sollte mit ssh-rsa AAAA… oder ähnlich beginnen.

Wenn dies funktioniert, können Sie damit fortfahren, Ihre neue schlüsselbasierte SSH-Authentifizierung zu testen.

Schritt 3 – Authentifizierung bei Ihrem Server mit SSH-Schlüsseln

Wenn Sie eine der obigen Prozeduren erfolgreich abgeschlossen haben, sollten Sie in der Lage sein, sich beim Remote-Host ohne das Passwort des Remote-Kontos anzumelden. Der Prozess ist größtenteils derselbe:

ssh [email protected]_host

Wenn dies das erste Mal ist, dass Sie eine Verbindung zu diesem Host herstellen (wenn Sie die letzte Methode oben verwendet haben), sehen Sie möglicherweise etwas Ähnliches wie dies:

Output
 The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established.
 ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
 Are you sure you want to continue connecting (yes/no)? yes

Dies bedeutet, dass Ihr lokaler Computer den Remote-Host nicht erkennt. Geben Sie ja ein und drücken Sie dann ENTER, um fortzufahren.

Wenn Sie keine Passphrase für Ihren privaten Schlüssel angegeben haben, werden Sie sofort angemeldet. Wenn Sie beim Erstellen des Schlüssels eine Passphrase für den privaten Schlüssel angegeben haben, müssen Sie diese jetzt eingeben. Anschließend wird für Sie eine neue Shell-Sitzung mit dem Konto auf dem entfernten System erstellt.

Wenn dies erfolgreich war, fahren Sie fort, um zu erfahren, wie Sie den Server sperren können.

Schritt 4 – Deaktivieren der Kennwortauthentifizierung auf Ihrem Server

Wenn Sie sich mit SSH ohne Passwort bei Ihrem Konto anmelden konnten, haben Sie die SSH-Schlüssel-basierte Authentifizierung für Ihr Konto erfolgreich konfiguriert. Ihr passwortbasierter Authentifizierungsmechanismus ist jedoch noch aktiv, was bedeutet, dass Ihr Server weiterhin Brute-Force-Angriffen ausgesetzt ist.

Bevor Sie die Schritte in diesem Abschnitt ausführen, vergewissern Sie sich, dass Sie entweder die schlüsselbasierte SSH-Authentifizierung für das root-Konto auf diesem Server konfiguriert haben oder vorzugsweise, dass Sie die schlüsselbasierte SSH-Authentifizierung für ein Konto auf diesem Server mit sudo-Zugriff konfiguriert haben. Dieser Schritt sperrt passwortbasierte Anmeldungen, so dass Sie unbedingt sicherstellen müssen, dass Sie weiterhin administrativen Zugriff erhalten.

Wenn die oben genannten Bedingungen erfüllt sind, melden Sie sich mit SSH-Schlüsseln bei Ihrem Remote-Server an, entweder als root oder mit einem Konto mit sudo-Rechten. Öffnen Sie die Konfigurationsdatei des SSH-Dämons:

sudo nano /etc/ssh/sshd_config

Suchen Sie innerhalb der Datei nach einer Direktive namens PasswordAuthentication. Diese kann auskommentiert sein. Heben Sie die Auskommentierung auf, indem Sie alle # am Anfang der Zeile entfernen, und setzen Sie den Wert auf no. Dadurch wird die Möglichkeit deaktiviert, sich über SSH mit Kontopasswörtern anzumelden:

/etc/ssh/sshd_config
PasswordAuthentication no

Speichern und schließen Sie die Datei, wenn Sie fertig sind. Um die soeben vorgenommenen Änderungen tatsächlich umzusetzen, müssen Sie den Dienst neu starten.

Bei den meisten Linux-Distributionen können Sie dazu den folgenden Befehl eingeben:

sudo systemctl restart ssh

Nach Abschluss dieses Schritts haben Sie Ihren SSH-Daemon erfolgreich so umgestellt, dass er nur noch auf SSH-Schlüssel reagiert.

Fazit

Sie sollten nun die SSH-Schlüssel-basierte Authentifizierung auf Ihrem Server konfiguriert haben und ausführen, so dass Sie sich ohne Angabe eines Kontopassworts anmelden können. Von hier aus gibt es viele Richtungen, in die Sie gehen können.