Wie entsperre ich ein Konto für die SSH-Autorisierung mit öffentlichem Schlüssel, aber nicht für die Kennwortautorisierung?


32

Das ssh lässt mich nicht einloggen, da der Account gesperrt ist. Ich möchte den Benutzer auf meinem Server für die Autorisierung öffentlicher Schlüssel über ssh entsperren, aber die Anmeldung mit Kennwort nicht aktivieren.

Ich habe es versucht:

# passwd -u username
passwd: unlocking the password would result in a passwordless account.
You should set a password with usermod -p to unlock the password of this account.

Authentifizierungsprotokolleinträge:

Mar 28 00:00:00 vm11111 sshd[11111]: User username not allowed because account is locked
Mar 28 00:00:00 vm11111 sshd[11111]: input_userauth_request: invalid user username [preauth]

Sie sollten dies ( meiner
Meinung nach

passwd -uist eine schlechte Idee. Siehe die Antwort von Giles unten.
Peter Jenkins

Antworten:


15

Entsperren Sie das Konto und geben Sie dem Benutzer ein komplexes Passwort, wie von @Skaperen vorgeschlagen.

Bearbeiten /etc/ssh/sshd_configund sicherstellen, dass Sie Folgendes haben:

PasswordAuthentication no

Stellen Sie sicher, dass die Zeile ( #zu Beginn) nicht kommentiert ist, und speichern Sie die Datei. Starten Sie abschließend den sshdDienst neu.

Bevor Sie dies tun, stellen Sie sicher, dass Ihre öffentliche Schlüsselauthentifizierung zuerst funktioniert.

Wenn Sie dies nur für einen (oder eine kleine Anzahl) Benutzer tun müssen, lassen Sie PasswordAuthenticationdie Option aktiviert und verwenden Sie stattdessen Match User:

Match User miro, alice, bob
    PasswordAuthentication no

Platzieren Sie sie am Ende der Datei, da sie bis zum nächsten MatchBefehl oder EOF gültig ist .

Sie können auch Match Group <group name>oder eine Verneinung verwendenMatch User !bloggs

Wie Sie in den Kommentaren erwähnt haben, können Sie es auch umkehren, sodass die Kennwortauthentifizierung im Hauptteil der Konfiguration deaktiviert ist, und MatchAnweisungen verwenden, um sie für einige Benutzer zu aktivieren:

PasswordAuthentication no
.
.
.
Match <lame user>
    PasswordAuthentication yes

Ich hatte den Eindruck, dass Miro das Passwort nur für eine Verwendung deaktivieren wollte . aber siehe meinen früheren Kommentar
Skaperen

@ Kaperen - Sie könnten gut Recht haben. Ich habe meine Antwort leicht geändert.
garethTheRed

Diese MatchSyntax sieht gut aus, aber ich werde versuchen, sie umzukehren. Aktivieren Sie die kennwortgeschützte Anmeldung für (wenige lahme) Benutzer.
Kravemir

@Miro - Das ist eine gute Idee. Ich habe sie zu meiner Antwort hinzugefügt, damit ich später darauf zurückgreifen kann.
garethTheRed

37

Was auch immer Sie tun, belassen Sie das Konto nicht in dem Zustand passwd -u, in dem es hinterlassen wurde , und geben Sie kein leeres Kennwort ein: Dies ermöglicht Anmeldungen ohne Eingabe eines Kennworts (außer über SSH, da SSH dies ablehnt).

Ändern Sie das Konto, um kein Kennwort zu haben, aber entsperrt zu werden. Ein Konto hat kein Kennwort, wenn der Kennwort-Hash in der Kennwortdatenbank kein Hash einer Zeichenfolge ist. Traditionell wird dafür eine einstellige Zeichenfolge wie *oder !verwendet.

Gesperrte Konten verwenden außerdem eine spezielle Markierung im Kennwortfeld, die dazu führt, dass die Zeichenfolge kein Hash einer Zeichenfolge ist. Der Marker ist systemabhängig. Unter Linux passwdmarkiert der Befehl gesperrte Kennwörter durch Setzen eines !am Anfang, und OpenSSH behandelt das Konto als gesperrt, wenn das Feld mit beginnt !. Andere Unix-Varianten verwenden in der Regel ähnliche, aber nicht identische Mechanismen. Seien Sie also vorsichtig, wenn Ihre Kennwortdatenbank von einem heterogenen Netzwerk gemeinsam genutzt wird.

Unter Linux können Sie den kennwortbasierten Zugriff auf ein Konto deaktivieren, während Sie den SSH-Zugriff (mit einer anderen Authentifizierungsmethode, normalerweise einem Schlüsselpaar) mit zulassen

usermod -p '*' username

Der Benutzer kann das Konto nicht wieder in ein Kennwort ändern, da er dazu ein gültiges Kennwort eingeben muss.

Wenn Sie möchten, können Sie stattdessen SSH so konfigurieren, dass die Kennwortauthentifizierung verweigert wird, unabhängig davon, ob das Konto ein Kennwort hat. Sie müssen immer noch dafür sorgen, dass SSH das Konto nicht als gesperrt betrachtet. Unter Linux müssen Sie beispielsweise !das Feld aus dem Kennwort entfernen (aber das Feld nicht leer lassen - stellen Sie es *wie oben beschrieben ein ). Fügen Sie zum Deaktivieren der Kennwortauthentifizierung für SSH eine PasswordAuthenticationDirektive zu /etc/sshd_configoder hinzu /etc/ssh/sshd_config(je nachdem, was sich auf Ihrem System befindet). Verwenden Sie einen MatchBlock, damit diese Anweisung nur für einen bestimmten Benutzer gilt. MatchBlöcke müssen erscheinen

…
Match User username
    PasswordAuthentication no

6
Danke - usermod -p '*' usernamehat einen Zauber gewirkt!
Homme Zwaagstra

1
Mit OpenSSHd können sich gesperrte Benutzer (z. B. Kennwort-Hash mit !Präfix) mit einer anderen Authentifizierungsmethode anmelden, wenn diese Option aktiviert UsePAM yesist sshd_config. Dies ist wahrscheinlich die Standardeinstellung bei den meisten Distributionen (z. B. bei Fedora).
Maxschlepzig

1
Ich habe ein Embedded-System ohne PAM, daher ist die Unterscheidung zwischen " '*'vs." sehr '!'nützlich.
Jpkotta

8

Sie müssen keine Passwörter aktivieren oder festlegen und sollten es auch nicht, wenn Sie bereits starke Schlüssel verwenden. Sperren Sie einfach Ihr Konto (sudo passwd -l Benutzername) aus einer vorhandenen Sitzung und korrigieren Sie Ihre SSH-Konfiguration.

Der Grund, warum dies passiert ist, ist wahrscheinlich, dass Sie eine der Standardeinstellungen des SSH-Dämons (in / etc / ssh / sshd_config) bearbeitet haben.

Ändern Sie dies in / etc / ssh / sshd_config und starten Sie SSH neu:

UsePAM yes

Im Allgemeinen empfehle ich, PAM aktiviert zu lassen, es sei denn, Sie haben einen guten Grund, PAM zu deaktivieren. Wenn Sie PAM in SSH aktivieren, können Sie sich auch mit entferntem Kennwort noch anmelden. Legen Sie auf keinen Fall ein leeres Passwort oder ähnliches fest. Das Sperren des Passwortfelds muss nicht das Sperren Ihres gesamten Kontos bedeuten.

Schneller Tipp bei der Kommunikation mit SSH: Lassen Sie eine andere Sitzung geöffnet (in einem anderen Fenster), wenn Sie Änderungen an Ihrer SSH-Konfiguration vornehmen, und testen Sie dann, ob Sie sich noch anmelden können. Wenn Sie Ihren Zugang versehentlich unterbrechen, können Sie ihn in Ihrer aktuellen Sitzung reparieren.

(Haftungsausschluss: Ich arbeite bei Userify, einem Anbieter von SSH-Schlüsselverwaltungssoftware.)


0

Ich hatte dieses Problem unter CentOS 7. Ich bin ein regelmäßiger Debian-basierter Linux-Benutzer, also war ich ein Fisch aus dem Wasser. Mir ist aufgefallen, dass es bei einigen Servern funktioniert hat und bei nur einem nicht. Das audit.log sagte nichts Nützliches und das secure.log gab auch nichts. Ich stellte fest, dass der einzige wirkliche Unterschied einige Unterschiede im Sicherheitskontext von Dateien und Verzeichnissen zwischen denen, die funktionierten, und denen, die nicht funktionierten, waren. Holen Sie sich die Sicherheit mit

sudo ls -laZ <user-home>/.ssh

des Verzeichnisses (ich gehe von vielen Standardeinstellungen für sshd_config aus).

Sie sollten einige ssh_home_tund user_home_tAttribute sehen. Wenn nicht, chconfügen Sie mit dem Befehl die fehlenden Attribute hinzu.

Beispielsweise

home="$(getent passwd <user> | cut -d: -f6)"
sudo chcon -R unconfined_u:object_r:ssh_home_t:s0 "$home".ssh
sudo chcon unconfined_u:object_r:user_home_t:s0 "$home"

In meinem Fall habe ich den Verdacht, dass der Benutzer auf nicht standardmäßige Weise erstellt wurde. Sein Zuhause war ein Verzeichnis in /var/lib.

Weitere Informationen unter: https://www.linuxquestions.org/questions/linux-security-4/selinux-preventing-ssh-login-with-~-ssh-authorized_keys-4175469538/


-2

Entsperren Sie das Konto und ändern Sie das Passwort in eine zufällige Zeichenfolge

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.