GNU/Linux >> LINUX-Kenntnisse >  >> Linux

Passwortloses SSH mit öffentlich-privaten Schlüsselpaaren

Wenn Sie regelmäßig mit SSH-Befehlen und Remote-Hosts interagieren, werden Sie möglicherweise feststellen, dass die Verwendung eines Schlüsselpaars anstelle von Passwörtern praktisch sein kann. Anstatt dass das entfernte System bei jeder Verbindung nach einem Passwort fragt, kann die Authentifizierung automatisch mit einem Paar aus öffentlichem und privatem Schlüssel ausgehandelt werden.

Der private Schlüssel bleibt sicher auf Ihrer eigenen Workstation, und der öffentliche Schlüssel wird an einem bestimmten Ort auf jedem Remote-System gespeichert, auf das Sie zugreifen. Ihr privater Schlüssel kann lokal mit einer Passphrase gesichert werden. Ein lokales Caching-Programm wie ssh-agent oder gnome-keyring ermöglicht es Ihnen, diese Passphrase regelmäßig einzugeben, anstatt jedes Mal, wenn Sie den Schlüssel verwenden, um auf ein Remote-System zuzugreifen.

[ Kostenloser Download:Spickzettel für fortgeschrittene Linux-Befehle. ]

Generieren eines Schlüsselpaars und Weitergeben des öffentlichen Schlüssels

Das Generieren Ihres Schlüsselpaars und das Verbreiten Ihres öffentlichen Schlüssels ist einfacher als es klingt. Gehen wir es durch.

Schlüssel generieren

Der minimale Aufwand zum Generieren eines Schlüsselpaars besteht darin, ssh-keygen auszuführen Befehl und Auswahl der Standardwerte bei allen Eingabeaufforderungen:

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/training/.ssh/id_rsa): 
Created directory '/home/training/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/training/.ssh/id_rsa.
Your public key has been saved in /home/training/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:qOoqJFfbfnBFMZ6WFsZQZfy6WXTfcknQEd0B+quTjHw [email protected]
The key's randomart image is:
+---[RSA 2048]----+
|        .+*+o.o+*|
|         oo*o. .o|
|         .*. ..  |
|    .  . o. . o..|
|   . o. S.   +..+|
|... ..o .   . +.+|
|o.  .. o. o .= o |
|.  .  . .o E+    |
|ooo    .  ...    |
+----[SHA256]-----+

Der Standardspeicherort zum Speichern der Schlüssel ist ~/.ssh Verzeichnis, das erstellt wird, falls es nicht existiert:

$ ls -al .ssh
total 16
drwx------. 2 training training 4096 Aug 12 07:43 .
drwx------. 5 training training 4096 Aug 12 07:43 ..
-rw-------. 1 training training 1843 Aug 12 07:43 id_rsa
-rw-r--r--. 1 training training  415 Aug 12 07:43 id_rsa.pub

Wenn Sie diesem Befehl erlauben, das Verzeichnis zu erstellen, wird auch sichergestellt, dass der Eigentümer und die Berechtigungen korrekt festgelegt sind. Einige Anwendungen verwenden keine Schlüssel, wenn die Berechtigungen für den privaten Schlüssel zu offen sind.

Die Datei mit der Endung .pub ist der öffentliche Schlüssel, der an die entfernten Systeme übertragen werden muss. Es ist eine Datei, die eine einzige Zeile enthält:Das Protokoll, den Schlüssel und eine E-Mail, die als Kennung verwendet wird. Optionen für das ssh-keygen Befehl können Sie einen anderen Bezeichner angeben:

$ cat .ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDZ4SCcMX1EK31G/qLyCs3PaFcWkx0QA61OwQNHYztvrg7iD/etN4S5UP6ugHjTcUvqD/fZJFBJeryK0Hz0FzejKYiJBxQuUqadyXFSW30VnW6mAzgNoz20rGc2mipUrsaqdBWWv5U7vX8sgjEHEgVHzq6pfWj681PtikJ8Dss1IvPiPvOoRz2jb1dQnnrAVqMDGeWbm4yjYQamPvnLo1Hy23NgXpZ7KXv9PuDDu3tqcoMUqFk7sHswMrCCUY9SWOD5JBbhD3JX4LPs68WWbETOqOQ3a9ebTsL3wRPSbuu/djhL9Qmd8fN2OaM2U2zFpeE3NzBq4KT/ml6RTv44EMuh [email protected]

Nach Generierung des Schlüsselpaares wird der ssh-keygen Der Befehl zeigt auch den Fingerabdruck und das randomart-Bild an, die für diesen Schlüssel eindeutig sind. Diese Informationen können an andere Personen weitergegeben werden, die möglicherweise Ihren öffentlichen Schlüssel verifizieren müssen.

Später können Sie diese anzeigen mit:

$ ssh-keygen -lv
Enter file in which the key is (/home/training/.ssh/id_rsa): 

Das -l listet den Fingerabdruck und den -v auf Option fügt die ASCII-Grafik hinzu.

Weitergabe des öffentlichen Schlüssels an ein Remote-System

Wenn die Kennwortauthentifizierung derzeit aktiviert ist, ist der einfachste Weg, den öffentlichen Schlüssel an den Remote-Host zu übertragen, die ssh-copy-id Befehl. Wenn Sie den Standardnamen für den Schlüssel verwendet haben, müssen Sie nur den entfernten Benutzer und Host angeben:

$ ssh-copy-id susan@streamer
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/training/.ssh/id_rsa.pub"
/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
susan@streamer's password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'susan@streamer'"
and check to make sure that only the key(s) you wanted were added.

Befolgen Sie die Anweisungen der Ausgabe und überprüfen Sie, ob Sie eine Verbindung mit dem Schlüsselpaar herstellen können. Wenn Sie eine Passphrase implementiert haben, werden Sie zur Eingabe der Passphrase aufgefordert, um den privaten Schlüssel zu verwenden:

$ ssh susan@streamer
Last login: Sat Aug 10 14:09:33 2019 from X.X.X.X

Untersuchen Sie die resultierende autorisierte Schlüsseldatei. Hier wurde der öffentliche Schlüssel angehängt. Wenn das Verzeichnis oder die Datei nicht existierte, wurde (oder wurden) sie mit dem richtigen Eigentum und den richtigen Berechtigungen erstellt. Jede Zeile ist ein einzelner autorisierter öffentlicher Schlüssel:

[susan@streamer ~]$ cat .ssh/authorized_keys 
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDZ4SCcMX1EK31G/qLyCs3PaFcWkx0QA61OwQNHYztvrg7iD/etN4S5UP6ugHjTcUvqD/fZJFBJeryK0Hz0FzejKYiJBxQuUqadyXFSW30VnW6mAzgNoz20rGc2mipUrsaqdBWWv5U7vX8sgjEHEgVHzq6pfWj681PtikJ8Dss1IvPiPvOoRz2jb1dQnnrAVqMDGeWbm4yjYQamPvnLo1Hy23NgXpZ7KXv9PuDDu3tqcoMUqFk7sHswMrCCUY9SWOD5JBbhD3JX4LPs68WWbETOqOQ3a9ebTsL3wRPSbuu/djhL9Qmd8fN2OaM2U2zFpeE3NzBq4KT/ml6RTv44EMuh [email protected]

Um den Zugriff für dieses Schlüsselpaar zu widerrufen, entfernen Sie die Zeile für den öffentlichen Schlüssel.

Es gibt viele andere Optionen, die zu dieser Zeile in der autorisierten Schlüsseldatei hinzugefügt werden können, um den Zugriff zu kontrollieren. Diese Optionen werden normalerweise von Administratoren verwendet, die die öffentlichen Schlüssel auf einem System mit Einschränkungen platzieren. Diese Einschränkungen können beinhalten, woher die Verbindung stammen kann, welche Befehle ausgeführt werden dürfen und sogar ein Datum, das angibt, wann die Annahme dieses Schlüssels eingestellt werden soll. Diese und weitere Optionen sind im sshd aufgeführt Manpage.

Passphrase ändern

Wenn Sie eine Passphrase auf Ihrem privaten Schlüssel ändern müssen oder wenn Sie zunächst eine leere Passphrase festlegen und diesen Schutz zu einem späteren Zeitpunkt wünschen, verwenden Sie den ssh-keygen Befehl mit dem -p Möglichkeit:

$ ssh-keygen -p
Enter file in which the key is (/home/training/.ssh/id_rsa): 
Key has comment '[email protected]'
Enter new passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved with the new passphrase.

Sie können zusätzliche Optionen hinzufügen, um den Schlüssel anzugeben (-f ) und die alte (-P ) oder neu (-N ) Passphrasen in der Befehlszeile. Denken Sie daran, dass alle auf der Befehlszeile angegebenen Passwörter in Ihrem Shell-Verlauf gespeichert werden.

Siehe ssh-keygen Manpage für zusätzliche Optionen.

Rotierende Schlüssel

Während der öffentliche Schlüssel an sich geteilt werden soll, denken Sie daran, dass jemand, der Ihren privaten Schlüssel erhält, diesen verwenden kann, um auf alle Systeme zuzugreifen, die über den öffentlichen Schlüssel verfügen. Diese Schlüsselpaare haben auch keine Gültigkeitsdauer wie GNU Privacy Guard (GPG)-Schlüssel oder Public Key Infrastructure (PKI)-Zertifikate.

Wenn Sie Grund zu der Annahme haben, dass ein privater Schlüssel gestohlen oder anderweitig kompromittiert wurde, sollten Sie dieses Schlüsselpaar ersetzen. Der alte öffentliche Schlüssel muss von allen Systemen entfernt werden, ein neuer Schlüssel muss mit ssh-keygen generiert werden , und der neue öffentliche Schlüssel muss auf die gewünschten entfernten Systeme übertragen werden.

Wenn Sie Schlüssel vorsichtshalber und ohne Bedenken hinsichtlich einer Gefährdung rotieren, können Sie das alte Schlüsselpaar verwenden, um die Übertragung des neuen öffentlichen Schlüssels zu authentifizieren, bevor Sie den alten Schlüssel entfernen.

Ist es jemals eine gute Idee, leere Passphrases zu verwenden?

Es gibt mehrere Dinge zu bedenken, wenn Sie eine leere Passphrase für Ihren privaten SSH-Schlüssel in Betracht ziehen.

Wie sicher ist die private Schlüsseldatei?

Wenn Sie dazu neigen, von mehreren Client-Systemen aus zu arbeiten und entweder mehrere Kopien Ihres Schlüssels haben oder eine Kopie auf Wechselmedien aufbewahren möchten, dann ist es wirklich eine gute Idee, eine Passphrase für den privaten Schlüssel zu haben. Diese Vorgehensweise dient zusätzlich zum Schutz des Zugriffs auf die Schlüsseldatei mit verschlüsselten Medien.

Wenn Sie jedoch nur eine Kopie des privaten Schlüssels haben und dieser auf einem gut gesicherten und nicht freigegebenen System aufbewahrt wird, dann ist eine Passphrase einfach eine weitere Schutzebene für alle Fälle.

Denken Sie daran, dass das Ändern der Passphrase auf einer Kopie nicht die Passphrase auf anderen Kopien ändert. Die Passphrase sperrt einfach den Zugriff auf eine bestimmte Schlüsseldatei.

Warum glauben Sie, dass Sie eine leere Passphrase benötigen?

Es gibt Fälle für Schlüssel mit leeren Passphrasen. Einige Dienstprogramme, die Dateien automatisch zwischen Systemen übertragen müssen, benötigen eine kennwortlose Methode zur Authentifizierung. Der kdump Dienstprogramm, wenn es so konfiguriert ist, dass es den Kernel mit SSH auf ein entferntes System ausgibt, ist ein Beispiel.

Eine weitere häufige Verwendung ist das Generieren eines Schlüsselpaars für ein Skript, das unbeaufsichtigt ausgeführt werden soll, beispielsweise von einem Cron-Job.

Wie wäre es mit einer mittleren Alternative?

Ein passphrasengeschützter privater Schlüssel selbst erfordert, dass die Passphrase jedes Mal eingegeben wird, wenn der Schlüssel verwendet wird. Dieses Setup fühlt sich nicht wie passwortloses SSH an. Es gibt jedoch Caching-Mechanismen, die es Ihnen ermöglichen, die Schlüssel-Passphrase einmal einzugeben und den Schlüssel dann immer wieder zu verwenden, ohne diese Passphrase erneut eingeben zu müssen.

OpenSSH wird mit einem ssh-agent geliefert Daemon und ein ssh-add Dienstprogramm zum Zwischenspeichern des entsperrten privaten Schlüssels. Der GNOME-Desktop hat auch einen Schlüsselring-Daemon, der Passwörter und Geheimnisse speichert, aber auch einen SSH-Agenten implementiert.

Die Lebensdauer des zwischengespeicherten Schlüssels kann mit jedem der Agenten oder beim Hinzufügen des Schlüssels konfiguriert werden. In vielen Fällen wird standardmäßig eine unbegrenzte Lebensdauer verwendet, der Cache wird jedoch gelöscht, wenn sich der Benutzer vom System abmeldet. Sie werden nur einmal pro Anmeldesitzung zur Eingabe der Passphrase aufgefordert.

Wenn es eine geplante Anwendung gibt, die außerhalb einer Benutzeranmeldesitzung ausgeführt werden muss, kann es möglich sein, einen geheimen oder anderen Passwortmanager zu verwenden, um das Entsperren des Schlüssels zu automatisieren. Beispielsweise speichert Ansible Tower Anmeldeinformationen in einer sicheren Datenbank. Diese Datenbank enthält einen privaten SSH-Schlüssel, der zum Herstellen einer Verbindung mit den Remote-Systemen (verwalteten Knoten) verwendet wird, sowie alle Passphrasen, die für diese privaten Schlüssel erforderlich sind. Sobald diese Anmeldeinformationen gespeichert sind, kann ein Job so geplant werden, dass ein Playbook regelmäßig ausgeführt wird.

Automatisierung der Weitergabe

Ein zentralisierter Identitätsmanager wie FreeIPA kann bei der Schlüsselweitergabe helfen. Laden Sie den öffentlichen Schlüssel als Attribut eines Benutzerkontos auf den Server hoch und geben Sie ihn dann nach Bedarf an die Hosts in der Domäne weiter. FreeIPA kann auch eine zusätzliche hostbasierte Zugriffskontrolle dafür bereitstellen, wo ein Schlüssel verwendet werden darf.

Schlüssel können auch mithilfe von Ansible-Modulen verteilt werden. Das openssh_keypair Modul verwendet ssh-keygen um Schlüssel und den authorized_key zu generieren Modul fügt autorisierte SSH-Schlüssel für bestimmte Benutzerkonten hinzu und entfernt sie.

Abschluss

SSH-Schlüsselpaare sind nur eine Möglichkeit, die Authentifizierung ohne Passwörter zu automatisieren. Die Authentifizierung über die Generic Security Services Application Program Interface (GSSAPI) ist auch üblich, wenn versucht wird, die Verwendung von Passwörtern in einem Netzwerk mit zentralisierter Nutzerverwaltung zu reduzieren. SSH-Schlüsselpaare sind die einfacher zu implementierende Option, wenn die einmalige Anmeldung (SSO) noch nicht verfügbar ist.

Viele Quellcode-Repositories gewähren Zugriff über SSH-Schlüssel. Sie können einen öffentlichen Schlüssel auf ein Konto in der Hosting-Organisation wie das Fedora-Kontosystem, GitLab oder GitHub-Sites hochladen und dieses Schlüsselpaar verwenden, um sich zu authentifizieren, wenn Sie Inhalte in Repositories ziehen und übertragen.


Linux
  1. So konfigurieren Sie SSH-Schlüssel mit cPanel

  2. Stellen Sie über SSH unter Linux oder Mac OS X eine Verbindung zu einem Server her

  3. Verwalten Sie SSH-Schlüsselpaare für Cloud-Server mit python-novaclient

  4. So richten Sie SSH-Schlüssel für die „kennwortlose“ SSH-Anmeldung unter Linux ein

  5. Verwendung desselben privaten SSH-Schlüssels auf mehreren Computern

So richten Sie die passwortlose SSH-Anmeldung in AlmaLinux ein

Richten Sie die passwortlose SSH-Anmeldung für mehrere Remote-Server mit Skript ein

Wie richte ich die ssh-schlüsselbasierte Authentifizierung für Github mithilfe der Datei ~/.ssh/config ein?

Passwortloser SSH-Login in 3 einfachen Schritten

Generieren und Verwenden eines SSH-Schlüssels mit PuTTY

Generieren Sie RSA-Schlüssel mit SSH mithilfe von PuTTYgen