Im Verlauf der Konfiguration eines Servers, bin ich auf eine falsche Haltung gegenüber den Policies einer Vielzahl von Linux Distros gestoßen.

Der vsftpd ist unter Linux mittlerweile wohl einer der meistgenutzen FTP Server. Die Konfiguration ist kinderleicht, wodurch wohl auch Einsteiger ihn bevorzugen. Allerdings hat er auch seine Tücken, wie das folgende Beispiel verdeutlicht.

Wenn man einem Systemuser keine Shell gibt, sondern /bin/false oder /bin/nologin definiert, zum Beispiel um den Login per SSH zu deaktivieren, so ist der Login über vsftpd auch nicht möglich.
 
 
 
Warum ist das so?

Der vsftpd versucht die Usershell, des Benutzers der sich gerade einloggt über PAM zu validieren.
 
 
 
Wie kann man den Benutzer trotzdem einloggen lassen?

Die ersten Google-Suchergebnisse schlagen vor, in der Datei /etc/shells, /bin/false und/oder /bin/nologin anzufügen, damit das System beide als valide Shells anerkennt.

Diese Änderung funktioniert, sie ist aber eher eine schlampige Methode.
Es hat einen Grund, warum /bin/false und /bin/nologin – obwohl auf jedem Linuxoid vertreten – nicht in der /etc/shells auftauchen.
Sie sind keine Shells!
 
 
Den korrekten Weg geht man, wenn man das Pferd von der anderen Seite sattelt.
Die Überprüfung in vsftpd ob die Usershell valide ist, zu deaktivieren.
 
Das geht sogar mit weniger Tipperei:
In der /etc/pam.d/vsftpd.

# Standard behaviour for ftpd(8).
auth    required        pam_listfile.so item=user sense=deny file=/etc/ftpusers onerr=succeed
 
# Note: vsftpd handles anonymous logins on its own.  Do not enable
# pam_ftp.so.
 
# Standard blurb.
@include common-account
@include common-session
 
@include common-auth
auth   required        pam_shells.so

die letzte Zeile durch eine Raute (#) kommentieren,
#auth required pam_shells.so,
fertig.

Schon validiert der vsftpd die Usershell nicht mehr und der Login ist ohne valide Shell möglich.