Schlüsselbasierte SSH-Anmeldung, für die sowohl Schlüssel als auch Kennwort erforderlich sind


8

Mein Problem ist: Ich habe erfolgreich eine RSA-Schlüssel-basierte SSH-Anmeldung an Bord vom System entwickelt. Wenn sich ein Client zum ersten Mal anmeldet, fragen Sie nach dem privaten Schlüssel und der Passphrase, die ebenfalls einwandfrei funktionieren. Bei der zweiten Anmeldung fragt ssh nicht nach einem privaten Schlüssel oder Passwort, sondern meldet sich direkt an Bord an.

Clientseitig Ubuntu 16.04 verwenden und an Bord Ubuntu anpassen.

Erstmalige Anmeldung mit folgendem Befehl:

ssh -i ~/.ssh/id_rsa user@board_ip //funktioniert gut

Zweites Mal:

ssh user@board_ip // frage niemals nach Passwort und öffentlichem Schlüssel - Problem

Erstes Mal:

ssh user@board_ip // kann sich ohne Schlüssel nicht anmelden - funktioniert einwandfrei

Nach meinem Verständnis habe ich einen Fehler in der Datei sshd_config auf der Karte gemacht. Ich habe mit den folgenden Einstellungen gespielt, aber es ist die ganze Zeit fehlgeschlagen.

StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
#PasswordAuthentication yes                                            
PermitEmptyPasswords no

Die Projektanforderung ist eine sichere Anmeldung, hauptsächlich auf ssh. Um eine sicherere SSH-Kennwort-basierte Anmeldung zu erreichen, haben wir auf die schlüsselbasierte Anmeldung umgestellt. Wie oben erklärt, nach Änderung aller Konfiguration. Für die SSH-Anmeldung sind auch ein privater Schlüssel und ein Kennwort erforderlich. Nach dem Abmelden und nach einer erneuten Anmeldung benötigt ssh weder Schlüssel noch Passwort. Die Projektanforderungen benötigen jedes Mal Schlüssel und Passwort.


2
Es klingt eher so, als würden die Anmeldeinformationen von Ihrem SSH-Agenten zwischengespeichert als als ein Fehler in der Konfiguration
Steeldriver

@steeldriver poste das als Antwort
Panther

@ user68186: Gemäß den Anforderungen des Projekts für mehr Sicherheit benötigen Sie bei jedem SSH-Versuch einen Schlüssel und ein Kennwort. Wenn Sie sich aus irgendeinem Grund zum ersten Mal anmelden und abmelden, verwendet jemand dieses System und versucht, sich zu diesem Zeitpunkt anzumelden, um ein Sicherheitskennwort und einen Schlüssel zu erhalten, die erforderlich sind.
Tejas Virpariya

Das "Problem", das Sie haben, ist, dass ssh-agent den Schlüssel und das Passwort speichert. siehe askubuntu.com/questions/737251/… und ähnliches. ssh und ssh-server funktionieren normal dies ist kein Konfigurationsproblem.
Panther

Antworten:


11

Es gibt zwei Möglichkeiten zum Konfigurieren ssh, um sowohl einen öffentlichen Schlüssel als auch ein Kennwort oder eine Passphrase zu erfordern.

Der Unterschied zwischen dem Passwort und der Passphrase:

Das Kennwort ist in diesem Zusammenhang das Kennwort, das dem Benutzer auf dem Servercomputer (der Karte) zugewiesen wurde. Wenn das Board nur ein Benutzerkonto hat, hat es nur ein Passwort. Wenn das Board über mehrere Benutzerkonten verfügt, sollten diese über eindeutige Kennwörter verfügen.

Die Passphrase ist mit dem privaten Schlüssel auf dem Client-Computer (lokal) und nicht mit dem Remote-Server-Computer (Board-Computer) verknüpft. Wenn Sie also zwei verschiedene Clientcomputer von Geräten verwenden, von denen aus ssh gesendet werden soll, müssen Sie Passphrasen für die privaten Schlüssel erstellen, die auf jedem lokalen Computer gespeichert sind. Wenn zwei verschiedene Benutzer von ihren jeweiligen lokalen Computern zum Server (Board) ssh müssen, benötigen sie ihre eigenen privat-öffentlichen Schlüsselpaare und eine eigene Passphrase, um ihre jeweiligen privaten Schlüssel zu entsperren.

Angenommen, Sie und ich müssen von unseren eigenen Laptops aus auf den Speicher-Server-Computer (das Board) ssh. Sie haben Ihren eigenen privaten Schlüssel und eine Passphrase für diesen privaten Schlüssel. Ich werde meinen eigenen privaten Schlüssel und seine Passphrase haben. Das Ergebnis dieser Anordnung ist, dass ich die Passphrase meines privaten Schlüssels jederzeit ändern kann, ohne es Ihnen mitzuteilen, oder irgendetwas am Servercomputer (der Karte) zu ändern. Ich kann sogar die Passphrase aus meinem privaten Schlüssel entfernen, ohne es Ihnen zu sagen.

Das andere Szenario ist, dass ich, wenn ich mehrere Server zum SSH habe und denselben privaten Schlüssel verwende, um mich bei allen Servern zu authentifizieren, dieselbe Passphrase verwenden muss, um auf SSH auf allen Servern zuzugreifen, mit denen ich arbeite, und nicht nur dein Board.

Methode 1. Öffentlicher Schlüssel mit Passphrase

Referenz: https://help.ubuntu.com/community/SSH/OpenSSH/Keys

Schritt 1. Fügen Sie dem vorhandenen öffentlich-privaten Schlüssel für jede Client- und Benutzerkombination eine Passphrase hinzu

Verwenden Sie für jeden Benutzer auf jedem Client-Computer oder -Gerät den folgenden Befehl, um eine Passphrase für das bestehende öffentlich-private Schlüsselpaar zu generieren:

ssh-keygen -p

Sie werden aufgefordert, den Speicherort für die Dateien anzugeben. Drücken Sie die Eingabetaste, um den Standardspeicherort zu übernehmen.

Wenn Sie bereits eine Passphrase festgelegt haben, werden Sie aufgefordert, die vorhandene Passphrase einzugeben. In diesem Fall haben Sie diesen Schritt bereits ausgeführt. Drücken Sie Ctrl+ C, um den Vorgang zu stoppen.

Als nächstes werden Sie aufgefordert, eine neue Passphrase einzugeben. Drücken Sie nicht die Eingabetaste! Geben Sie eine lange und schwer zu erratende Passphrase ein, die leicht zu merken ist. Sie werden aufgefordert, die Passphrase erneut einzugeben.

Wenn Sie kein öffentlich-privates Schlüsselpaar haben, generieren Sie es mit dem folgenden Befehl. Sie werden aufgefordert, eine Passphrase hinzuzufügen, falls Sie eine benötigen:

ssh-keygen -t rsa

Jedes Mal, wenn Sie versuchen, sich beim SSH-Server anzumelden, werden Sie aufgefordert, diese Passphrase einzugeben. Dies kann für das Benutzerkennwort des SSH-Servers unterschiedlich sein. Jeder Benutzer kann seine eigene Passphrase haben. Wenn sich ein Benutzer von verschiedenen Clients (Laptop, Telefon usw.) aus anmelden muss, muss er diesen Vorgang für jeden Client wiederholen. Sie kann verschiedene Passphrasen für verschiedene Kunden wählen.

Schritt 2. Kopieren Sie den öffentlichen Schlüssel nur dann auf den Server, wenn der Schlüssel neu ist

Geben Sie auf Ihrem Client-Computer Folgendes ein:

ssh-copy-id -i ~/.ssh/id_rsa user@board_ip

Es wird nach dem Passwort des Benutzers auf dem Remote-Server gefragt. Denken Sie daran, dass die kennwortbasierte Anmeldung aktiviert sein muss, damit dies funktioniert.

Wiederholen Sie dies für alle Benutzer und alle Clientgeräte.

Schritt 3. Testen Sie, ob es funktioniert

Versuchen Sie, sich beim Server anzumelden, indem Sie Folgendes eingeben:

ssh user@board_ip 

Wenn alles gut geht, werden Sie aufgefordert, die in Schritt 2 erstellte Passphrase einzugeben. Dies ist nicht das Benutzerkennwort, nach dem Sie in Schritt 3 gefragt wurden.

Wenn Sie die Eingabeaufforderung zur Eingabe des Benutzerkennworts sehen, stimmt etwas nicht. Fahren Sie nicht mit dem nächsten Schritt fort, bis dies funktioniert.

Schritt 4. Deaktivieren Sie die kennwortbasierte Anmeldung

Sobald jeder Benutzer und seine jeweiligen Clientgeräte über eigene öffentlich-private Schlüsselpaare und Passphrasen ihrer Wahl verfügen, benötigen Sie keine kennwortbasierte Anmeldung mehr. Es ist am besten, diese Methode zu deaktivieren. Wenn Sie diese Option aktiviert lassen, kann jeder Benutzer ohne das öffentlich-private Schlüsselpaar versuchen, das Kennwort des Benutzers @ board-ip zu erraten.

Bearbeiten Sie auf dem SSH-Server, der Karte, die Datei /etc/ssh/sshd_configund ändern Sie:

#PasswordAuthentication yes

lesen:

PasswordAuthentication no

Beachten Sie, dass das #nicht in der zweiten Zeile vorhanden ist und das yesjetzt ist no.

Starten Sie den SSH-Dienst auf dem Server neu, indem Sie:

sudo service ssh restart

Wenn dies nicht funktioniert, starten Sie die Karte neu.

Es ist vollbracht. Die Passphrase wird im Client wahrscheinlich von Gnome-Keyring zwischengespeichert, bis sich der Benutzer vom lokalen Computer abmeldet. Daher wird die Phass-Phrase nur einmal pro Sitzung abgefragt.

Was als nächstes kommt, ist eine andere Alternative. Sie müssen entweder 1 oder 2 tun.

Methode 2. Öffentlicher Schlüssel und Benutzerkennwort erforderlich

Referenz: /security/17931/possible-to-use-both-private-key-and-password-authentication-for-ssh-login

Schritt 1. Entfernen Sie die Passphrase für jede Client- und Benutzerkombination aus dem privaten Schlüssel, falls vorhanden

Verwenden Sie für jeden Benutzer auf jedem Client-Computer oder -Gerät den folgenden Befehl, um die vorhandene Passphrase für jedes öffentlich-private Schlüsselpaar zu entfernen:

ssh-keygen -p

Sie werden aufgefordert, den Speicherort für die Dateien anzugeben. Drücken Sie die Eingabetaste, um den Standardspeicherort zu übernehmen.

Wenn Sie eine Passphrase haben, werden Sie aufgefordert, diese einzugeben. Wenn Sie nicht zur Eingabe einer vorhandenen Passphrase aufgefordert werden, sind Sie fertig. Drücken Sie Ctrl+ C, um den Vorgang zu stoppen.

Andernfalls geben Sie die vorhandene Passphrase ein und fahren Sie fort.

Als nächstes werden Sie aufgefordert, eine Passphrase einzugeben. Drücken SieEnter zweimal, um die vorhandene Passphrase aus dem privaten Schlüssel zu entfernen.

Wenn Sie kein öffentlich-privates Schlüsselpaar haben, generieren Sie es mit dem folgenden Befehl. Sie werden aufgefordert, eine Passphrase hinzuzufügen, falls Sie eine benötigen:

ssh-keygen -t rsa

Wenn sich ein Benutzer von verschiedenen Clients (Laptop, Telefon usw.) aus anmelden muss, muss er diesen Vorgang für jeden Client wiederholen.

Schritt 2. Kopieren Sie den öffentlichen Schlüssel nur dann auf den Server, wenn der Schlüssel neu ist

Geben Sie auf Ihrem Client-Computer Folgendes ein:

ssh-copy-id -i ~/.ssh/id_rsa user@board_ip

Es wird nach dem Passwort des Benutzers auf dem Remote-Server gefragt. Denken Sie daran, dass die kennwortbasierte Anmeldung aktiviert sein muss, damit dies funktioniert.

Wiederholen Sie dies für alle Benutzer und alle Clientgeräte.

Schritt 3. Testen Sie, ob öffentliche Schlüssel verwendet werden

Versuchen Sie, sich beim Server anzumelden, indem Sie Folgendes eingeben:

ssh user@board_ip 

Wenn alles gut geht, werden Sie nicht aufgefordert, ein Passwort oder eine Passphrase einzugeben. Das ist normal. Dies zeigt, dass der öffentliche Schlüssel ordnungsgemäß auf dem SSH-Server (der Karte) installiert ist und funktioniert. Wir werden die Einstellung so ändern, dass im nächsten Schritt erneut nach dem Passwort gefragt wird.

Schritt 4. Setup für öffentlichen Schlüssel und Passwort

Melden Sie sich beim SSH-Server (der Karte) an und bearbeiten Sie die /etc/ssh/sshd_configDatei. Fügen Sie der Datei die folgende Zeile hinzu:

AuthenticationMethods publickey,password

Warnung: Stellen Sie sicher, dass das PasswordAuthenticationwie folgt aussieht:

#PasswordAuthentication yes

Dies ist das Standardverhalten. Sie können das #am Anfang behalten oder entfernen . Wenn diese Einstellung jedoch nozusammen mit der gerade hinzugefügten Zeile festgelegt ist, kann sich niemand mit dem Server anmelden ssh. Wenn Sie gesperrt werden, müssen Sie physisch zum Remote-Server gehen, ihn an Tastatur, Monitor usw. anschließen und sich lokal anmelden und diese Datei bearbeiten, um das Problem zu beheben.

Warnung beenden

Starten Sie den SSH-Dienst auf dem Server neu, indem Sie:

sudo service ssh restart

Wenn dies nicht funktioniert, starten Sie die Karte neu.

Schritt 5. Testeinbruch

Suchen Sie einen neuen Computer oder melden Sie sich mit einem neuen Benutzernamen am Client-Computer an, z. B. user2. Dieser Benutzer sollte keine öffentlich-privaten Schlüsselpaare in seinem /home/$USER/.ssh/Ordner haben. Wir werden so tun, als wäre user2 der Hacker, der das Passwort von user @ board_ip irgendwie herausgefunden hat, und versuchen, in dieses System zu ssh.

Geben Sie als Benutzer2 vom Client-Computer Folgendes ein:

ssh user@board_ip

Wenn Sie sich nur mit dem Passwort anmelden können, hat es nicht funktioniert. Jeder, der das Passwort hat oder es erraten kann, kann sich beim Board anmelden. Sie brauchen den Schlüssel nicht.

Wenn Sie eine erhalten permission deniedund die Anmeldung fehlschlägt, funktioniert die doppelte Authentifizierung von öffentlichem Schlüssel und Kennwort.

Hoffe das hilft


0

Das Problem ist, dass dies ~/.ssh/id_rsadie Standardeinstellung für einen öffentlichen SSH-Schlüssel in Ubuntu ist. Daher müssen Sie -i ~/.ssh/id_rsanach dem Schlüsselaustausch keinen SSH-Befehl id_rsahinzufügen , um das Schlüsselpaar zu verwenden .

Um dieses Verhalten zu vermeiden, erstellen Sie das SSH-Schlüsselpaar mit einem anderen Namen. Es wird nur verwendet, wenn Sie es mit der -iOption angeben .

Beispiel:
Wenn Sie den Schlüssel mit dem Namen user_ssh_rsaim Ausgangsverzeichnis des Benutzers erstellen :

ssh-keygen -t rsa -f ~/.ssh/user_ssh_rsa

Tauschen Sie dann den Schlüssel mit dem Remote-Server aus und geben Sie das Kennwort für den Benutzer auf dem Remote-System ein, wenn Sie dazu aufgefordert werden:

ssh-copy-id -i ~/.ssh/user_ssh_rsa user@board_ip

Anmelden mit:

ssh -i ~/.ssh/user_ssh_rsa user@board_ip

Melden Sie sich an, ohne zur Eingabe eines Kennworts aufzufordern, da der neu erstellte Schlüssel verwendet wird.

Verwenden von:

ssh -user@board_ip

Fordert zur Eingabe des Kennworts auf, da das Schlüsselpaar nicht automatisch gefunden wird.
Dies hängt davon ab, ob Sie den bereits freigegebenen Schlüssel bei entfernt haben~/.ssh/id_rsa


Ich habe mit beiden Optionen versucht, erstens benenne ich id_rsa um und zweitens benenne ich den Ort von id_rsa um und ändere ihn dauerhaft und lösche auch permanent id_rsa aus ~ / .ssh / location, aber das gleiche Ergebnis. ssh erlaubt den Zugriff ohne Schlüssel und Passwort. Ich möchte Sicherheit bei jedem SSH-Anmeldeversuch.
Tejas Virpariya

1
Haben Sie id_rsa und id_rsa.pub entfernt? Andernfalls muss es sich um ein Problem beim Zwischenspeichern von SSH-Agenten handeln.
Arronical

Ich habe den privaten Schlüssel entfernt, aber den öffentlichen Schlüssel nicht berührt.
Tejas Virpariya

Ich denke, Sie müssten beide entfernen.
Arronical
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.