it-swarm.com.de

Sollte ich die Kennwörter der Benutzer löschen, sobald ich die Authentifizierung mit öffentlichem Schlüssel für SSH eingerichtet habe?

Es ist am besten, öffentliche Schlüssel für SSH zu verwenden. Mein sshd_config Hat also PasswordAuthentication no.

Einige Benutzer melden sich nie an, z. ein SFTP-Benutzer mit Shell /usr/sbin/nologin. Oder ein Systemkonto.

So kann ich mit adduser gary --Shell /usr/sbin/nologin --disabled-password Einen solchen Benutzer ohne Passwort erstellen.

Ist das eine gute/schlechte Idee? Gibt es Konsequenzen, die ich nicht berücksichtigt habe?

20
lonix

Wenn Sie Root-Zugriff auf den Server haben und SSH-Schlüssel für Ihre Benutzer neu generieren können, falls diese diese verlieren

UND

sie sind sicher, dass ein Benutzer (als Person) nicht mehrere Benutzerkonten hat und zwischen denen in einer SSH-Sitzung wechseln muss (nun, sie können auch mehrere öffnen) SSH-Sitzungen, falls erforderlich)

UND

sie benötigen nie "physischen" (über Tastatur + Monitor oder über Remote-Konsole für eine VM) Zugriff auf den Server

UND

keine Benutzer haben einen kennwortgesteuerten Sudo Zugriff (d. h. sie haben entweder überhaupt keinen Sudo-Zugriff oder Sudo-Zugriff mit NOPASSWD).

Ich denke du wirst gut sein.

Wir haben viele Server bei der Arbeit, die so konfiguriert sind (nur einige Konten benötigen Zugriff auf die VM über die VMware-Remotekonsole, die anderen stellen nur eine Verbindung über SSH mit Pubkey-Authentifizierung her).

35
Mr Shunz

Diese ursprünglich erwähnte Frage passwd --delete <username> ist unsicher : Damit ist das verschlüsselte Passwortfeld in /etc/shadow Vollständig leer.

username::...

Wenn Sie Ihr sshd so konfiguriert haben, dass die Kennwortauthentifizierung abgelehnt wird, ist dies mit SSH sicher. Wenn jedoch ein anderer Dienst auf Ihrem System die Kennwortauthentifizierung verwendet und nicht für konfiguriert ist Null-Passwörter ablehnen, dies ermöglicht den Zugriff ohne Passwort! Das wollen Sie nicht.


adduser --disabled-passwd Erzeugt einen /etc/shadow - Eintrag, bei dem das verschlüsselte Kennwortfeld nur ein Sternchen ist, d. H.

username:*:...

Dies ist "ein verschlüsseltes Passwort, das niemals erfolgreich eingegeben werden kann", d. H. Dies bedeutet, dass das Konto gültig ist und Anmeldungen technisch zulässt, die Authentifizierung durch das Passwort jedoch nicht erfolgreich ist . Wenn Sie also andere auf der Kennwortauthentifizierung basierende Dienste auf Ihrem Server haben, wird dieser Benutzer für diese blockiert.

Für diesen Benutzer funktionieren nur Authentifizierungsmethoden, die etwas anderes als das Standardkontokennwort verwenden (z. B. die SSH-Schlüssel), für jeden Dienst, der die Systemkennwortdateien in diesem System verwendet. Wenn Sie einen Benutzer benötigen, der sich nur mit SSH-Schlüsseln anmelden kann, ist dies das, was Sie möchten.

Wenn Sie ein vorhandenes Konto auf diesen Status setzen müssen, können Sie diesen Befehl verwenden:

echo 'username:*' | chpasswd -e

Es gibt einen dritten speziellen Wert für das verschlüsselte Passwortfeld: adduser --disabled-login, Dann enthält das Feld nur ein einziges Ausrufezeichen.

username:!:...

Wie das Sternchen macht dies die erfolgreiche Kennwortauthentifizierung unmöglich, hat aber auch eine zusätzliche Bedeutung: Es markiert das Kennwort für einige Verwaltungstools als "gesperrt". passwd -l Hat den gleichen Effekt, indem dem vorhandenen Kennwort-Hash ein Ausrufezeichen vorangestellt wird, wodurch die Kennwortauthentifizierung erneut nicht verwendet werden kann.

Aber hier ist eine Falle für Unvorsichtige: im Jahr 2008 die Version des Befehls passwd, die aus dem alten Paket shadow stammt wurde geändert, um passwd -l von "Sperren des Kontos" auf "Sperren des Passworts" neu zu definieren. Der angegebene Grund ist "für die Kompatibilität mit anderen passwd-Versionen".

Wenn Sie (wie ich) dies vor langer Zeit gelernt haben, kann es eine böse Überraschung sein. Es hilft nichts, dass adduser(8) diese Unterscheidung anscheinend auch noch nicht kennt.

Der Teil, der das Konto für alle Authentifizierungsmethoden deaktiviert, setzt tatsächlich einen Ablaufdatumwert von 1 für das Konto: usermod --expiredate 1 <username>. Vor dem Jahr 2008 wurde passwd -l, Das aus dem dafür verwendeten Quellkit shadow stammt zusätzlich zu dem Kennwort ein Ausrufezeichen vorangestellt - aber nicht mehr TU das.

Das Debian-Paket-Änderungsprotokoll sagt:

  • debian/patches/494_passwd_lock-no_account_lock: Wiederherstellen des vorherigen Verhaltens von passwd -l (geändert in # 389183): Sperren Sie nur das Kennwort des Benutzers, nicht das Konto des Benutzers. Dokumentieren Sie auch explizit die Unterschiede. Dadurch wird ein Verhalten wiederhergestellt, das mit früheren Versionen von passwd und anderen Implementierungen gemeinsam ist. Schließt: # 492307

Die Fehlerhistorien für Debian-Fehler 492307 und Fehler 38918 können hilfreich sein, um das Denken dahinter zu verstehen.

27
telcoM