Frage Was ist der Unterschied zwischen / sbin / nologin und / bin / false?


Ich habe oft gehört, dass es empfohlen wurde, dass ein Benutzerkonto deaktiviert werden sollte, indem man seine Shell auf setzt /bin/false. Aber auf meinen bestehenden Linux-Systemen sehe ich, dass eine große Anzahl bestehender Konten (alle Dienstkonten) eine Shell von /sbin/nologin stattdessen.

Ich sehe von der Manpage das /sbin/nologin Gibt eine Nachricht an den Benutzer aus, die besagt, dass das Konto deaktiviert ist, und wird dann beendet. Vermutlich /bin/false würde nichts drucken.

Das sehe ich auch /sbin/nologin ist aufgeführt in /etc/shells, während /bin/false ist nicht.

Die man-Seite besagt, dass FTP den Zugriff für Benutzer mit einer Shell deaktiviert nicht gelistet in /etc/shells und impliziert, dass andere Programme dasselbe tun können. Bedeutet das, dass jemand FTP mit einem Konto, das hat /sbin/nologin als seine Schale?

Was ist der Unterschied hier? Welchen davon sollte ich verwenden, um ein Benutzerkonto zu deaktivieren, und unter welchen Umständen? Welche anderen Effekte hat eine Auflistung in /etc/shells haben?


65
2018-06-28 04:58


Ursprung


unix.stackexchange.com/questions/10852/ ... - dmourati
Als allgemeine Information, die funktioniert. Ich denke gerade an die Systemadministration. - Michael Hampton♦
Nur als Hintergrund gedacht. - dmourati


Antworten:


/bin/false ist ein Dienstprogramm, Begleiter zu /bin/trueDies ist in gewissem Sinne nützlich, um sicherzustellen, dass Unix vollständig ist. Jedoch wurden emergente Zwecke für diese Programme gefunden; Betrachten Sie die BASH-Anweisung /some/program || /bin/true, die immer boolesch sein wird - evaluate to true ($? = 0) egal die Rückkehr von /some/program.

Eine emergente Verwendung von /bin/falseWie Sie festgestellt haben, ist dies eine Null-Shell für Benutzer, die sich nicht anmelden dürfen. Das System verhält sich in diesem Fall genau so, als würde die Shell nicht ausgeführt.

POSIX (obwohl ich falsch liegen kann und es der SUS sein kann), beschränkt beide Befehle, genau das zu tun, nur den entsprechenden booleschen Wert zurückzugeben.

/sbin/nologin ist ein BSD-Dienstprogramm, das ein ähnliches Verhalten hat /bin/false (gibt boolean false zurück), druckt aber auch die Ausgabe als /bin/false ist verboten zu tun. Dies soll dem Benutzer helfen zu verstehen, was passiert ist, obwohl in der Praxis viele Terminalemulatoren einfach schließen, wenn die Shell beendet wird, was die Nachricht in einigen Fällen sowieso unlesbar macht.

Es gibt wenig Zweck zu notieren /sbin/nologin im /etc/shells. Der Standardeffekt von /etc/shells ist es, die Programme aufzulisten, die mit verwendet werden dürfen chsh wenn Benutzer ihre eigene Shell ändern (und es gibt keinen glaubwürdigen Grund, ihre eigene Shell zu ändern) /sbin/nologin). Der Superuser kann die Shell eines beliebigen Benutzers ändern. Sie können jedoch beide auflisten /sbin/nologin und /bin/false im /etc/rsh, die Benutzern mit diesen Shells verbieten, ihre Shell mithilfe von zu ändern chsh in dem unglücklichen Fall, dass sie eine Muschel bekommen.

FTP-Daemons können Benutzern mit einer Shell, die sich nicht in / etc / shells befindet, den Zugriff verweigern, oder sie können jede andere Logik verwenden, die sie wünschen. Laufendes FTP ist auf jeden Fall zu vermeiden sftp (die ähnliche Funktionalität bietet) ist ähnlich, aber sicher. Einige Websites verwenden /sbin/nologin um den Zugriff auf die Shell zu deaktivieren und gleichzeitig den sftp-Zugriff durch Einfügen zu ermöglichen /etc/shells. Dies kann eine Hintertür öffnen, wenn der Benutzer Cronjobs erstellen darf.

In beiden Fällen, scp funktioniert nicht mit einer ungültigen Shell. scponly kann in diesem Fall als Shell verwendet werden.

Darüber hinaus beeinflusst die Wahl der Shell die Funktionsweise von su - (AKA su -l). Insbesondere die Ausgabe von /sbin/nologin wird auf stdout gedruckt, wenn es die Shell ist; Dies kann nicht der Fall sein /bin/false. In beiden Fällen laufen Befehle mit su -cl wird versagen.

Endlich die Antwort:

Um ein Konto zu deaktivieren, hängen Sie von keiner dieser Optionen ab, sondern setzen Sie die Shell auf /sbin/nologin zu Informationszwecken (es sei denn, /sbin/nologin ist in /etc/shellsan welcher Stelle solltest du verwenden /bin/false, was nicht sein sollte). Setzen Sie stattdessen das Passwortfeld in /etc/passwd zu !, die garantiert ist von crypt um für keine Passwörter gültig zu sein. Überlegen Sie, ob Sie den Hashwert festlegen /etc/shadow der gleiche Weg, um Fehler zu vermeiden. passwd -l werde das für dich tun.

Eine dritte Möglichkeit, ein Konto zu deaktivieren, besteht darin, das Feld für das Ablaufdatum des Kontos auf ein altes Datum zu setzen (z. B. usermod --expiredate 1). Dies verhindert Logins für den Fall, dass Ihr Setup es Benutzern erlaubt, sich mit ihrem Unix-Account ohne Passwort zu authentifizieren und der Service, den sie benutzen, keine Shell benötigt.


68
2018-06-28 05:34



Während diese Antwort die verschiedenen Optionen perfekt zusammenfasst (und die Frage beantwortet), habe ich das Bedürfnis verspürt, auf eine nützliche Ressource für diesen Anwendungsfall hinzuweisen, die zumindest in den Debian - Repositories verfügbar ist titantools Paket: noshell. Diese Pseudo-Shell bietet Überwachungsfunktionen und meldet sich bei Syslog an, mit denen versucht wird, Konten zu verwenden noshellals seine Shell, während immer noch der Zugriff verweigert. - dawud
Es ist keineswegs apokryph, aber es ist tatsächlich ziemlich üblich unter den Systemadmins eines bestimmten Jahrgangs (Husten) zu verwenden /bin/false als Login-Shell für Leute, die sich nicht einloggen sollten. - MadHatter
Apokryph in dem Sinne, dass es nicht der ursprüngliche Verwendungszweck ist. Ich habe nicht anachronistisch gesagt; Ich sehe es jeden Tag :) - Falcon Momot
Die Deaktivierung des Kontos durch ein ungültiges Passwort funktioniert mit ssh nicht so gut. Wenn der Benutzer zuvor die Authentifizierung mit öffentlichen Schlüsseln eingerichtet hat, könnte er trotzdem einsteigen. - joshudson
sshd ist dokumentiert, um zu überprüfen, dass Konten, die auf bestimmte Arten gesperrt sind (Passwort-Hashes beginnend mit! werden speziell erwähnt) auch mit Pubkey-Authentifizierung. - Falcon Momot


Nach einigen Nachforschungen hängt die Methode, die Sie verwenden, davon ab, was Sie sperren müssen. Wenn sich ein Benutzer mit diesem Set an der Shell anmeldet, erhält er eine Nachricht mit der Bedeutung von This account is currently unavailable. Beachten Sie, dass Sie dies ändern können, indem Sie die Datei erstellen /etc/nologin.txt zumindest auf RHEL-Derivaten.

Wie du weißt /bin/false ist keine Hülle. So funktioniert es, dass es false zurückgibt, das sich sofort nach dem Beenden der Binärdatei ausloggt. Beachten Sie, dass /bin/true würde den gleichen Effekt erzielen.

Bezüglich deiner FTP-Frage: Ja, du hast Recht, wenn die Shell auf gesetzt ist /sbin/nologin ermöglicht Benutzern, sich währenddessen bei FTP anzumelden /bin/false oder /bin/true verhindert vollständig, dass sich der Benutzer anmeldet irgendein Bedienung.

Deshalb, /bin/false oder /bin/true Am besten verhindern Sie, dass sich ein Benutzer an einem Dienst anmeldet /sbin/nologin Benutzer können sich weiterhin bei anderen Diensten als SSH oder der lokalen Konsole anmelden, während sie dem Benutzer Feedback geben, dass das Konto inaktiv ist und am besten verwendet wird, wenn nur SSH / lokale Konsole gesperrt werden muss.


12
2018-06-28 05:30





Ähm, hat irgendjemand Versuchen um zu beweisen, dass / bin / false den FTP-Zugang verbieten würde?

Ich habe gerade die Shell meines Benutzers in / bin / false geändert und konnte problemlos mit FTP arbeiten.

Ich benutze / dev / null zu vollständig Sperren Sie den Benutzer (gut, außer E-Mail, sie können immer noch POP3).


2
2017-09-01 02:24



Hattest du es? /etc/shells? Wie ist Ihr FTP-Server konfiguriert? - Michael Hampton♦
Es gibt keine Regel, die besagt, dass ein Benutzer eine Shell benötigt, um sich bei einem FTP-Server anzumelden. - Petter H
Es wird es auf einigen FTP-Daemons und nicht anderen verbieten. Es gibt eine Menge Unterschiede in der Funktionalität zwischen den verschiedenen. Die klassische Implementierung verbietet den Zugriff auf jeden, der keine Shell hat, aber das bedeutet nicht, dass alle Implementierungen dies müssen. - Falcon Momot