vsftp – temporary FTP access for a defined list of users

We adminster Opensuse servers for some of our customers at server hosters – e.g. at Strato, a Telekom subsidiary. Sometimes some web server files have to be upgraded either by us or by specific users of the customer. But only sometimes. Under normal operative conditions the FTP access to the server shall not be allowed.

To enable a FTP service we have installed “vsftp”. We further want the FTP users of our customers not to be able to access a shell on the server and restrict their FTP access to a certain directory. However, some of our own admins shall be able to access other server directories by FTP also.

Some basics of how you may set up and configure a vsftp server on an Opensuse system have already been described in my article
vsftp unter Opensuse 12.2 und 12.3.
The basic settings are valid for Opensuse 13.1, too. The settings discussed in the named article already restricted FTP users to a specific directory.

Sporadic FTP access

We solve the sporadic access requirement as follows:
The firewall on the server blocks all ports (with the exception of a dedicated SSH-Port for certificate based SSH logins and http/https ports) under normal operation conditions. But a trained user at the customer site can open a SSH connection and is allowed to start (but not change) a shell script (running with root rights) that temporarily opens ports for FTP connections for a defined IP (the WAN IP of the customer) to the vsftp server.

A simplified example for such a shell script that manipulates a IP chain called “zugriff” may look like:

iptables -N zugriff 
iptables -F zugriff 
iptables -A zugriff -p TCP -s $myip --dport ftp -j ACCEPT
iptables -A zugriff -p TCP -s $myip --dport 62050:62100 -j ACCEPT
iptables -t filter -I INPUT 4 -j zugriff
echo "vsftp port and IP rules were set for : " $myip
systemctl start vsftpd.service
echo "vsftp started"

A related simple stop script would be:

iptables -F zugriff
iptables -t filter -D INPUT -j zugriff
systemctl stop vsftpd.service
echo "FTP services stopped. FTP ports blocked in firewall."

The choice of the passive vsftp ports (in our example the range between 62050 and 62200) must of course correspond to the passive port settings in the vsftp configuration. Set the following options in the vsftpd.conf file:


You may also combine the script commands given above with further commands to start a time interval after which the ports are blocked automatically again. (To prevent possible harm if your trained customer user forgets to stop the vsftp service manually by the given stop scipt).

Grant FTP access to users of a defined list

The vsftp configuration given in my previous article vsftp unter Opensuse 12.2 und 12.3. allows for the access of all locally defined users on the server. They get chrooted to a defined chroot directory.

Note that the single FTP user discussed in the named article got the shell “/bin/false”. Note further that we did not allow anonymous FTP access.

At our customer several users with different UIDs shall get the right to transfer files to the server. The different UIDs shall give us a chance to distinguish their actions in log protocols. (Note that logging the action of users may require special working contract conditions in Germany).

All of the FTP users become members of a special
group. The main FTP directory – let it e.g. be “/srv/www/htdocs/webs” – which becomes their home dir and to which they are restricted by the vsftpd options


– gets group ownership of this special group. In addition the SGID bit is set. All of the customer’s FTP users get the shell “bin/false”.

Now, how to restrict the FTP access to defined users among others (e.g. from our own company) and how to extend the directory access for our own admins?

To restrict FTP access to users of a defined list requires the following options:


and a file “/etc/vsftpd.user_list” with just the UIDs of the users you want to rant FTP access – each UID in a separate line. The first option tells the vsftpd daemon that the users enlisted in the file “/etc/vsftpd.user_list” get the FTP access granted and shall not be denied it.

Note 1: I had considerable difficulties with my first userlist file, which I had generated and edited with vi on the server. Probably, I did some mistypes whilst editing… Be sure that your userlist file does not contain any special characters not visible on your terminal and that each UID is followed by a line break! Create the file from scratch if you experience unexplainable difficulties or read errors for the file in you FTP client. See: https://groups.google.com/forum/#!msg/alt-f/jtslOMt5aTA/1TW2kGkvmbkJ

Note 2: The file must be readable to the user running the vsftpd process on the server. On Opensuse systems this is presently “root” or “ftpsecure” – depending a bit on how you start the process. You may change ownership of the file to the user “ftpsecure” and drop the standard readability right for “others” – depending on security conditiosn.

Due to the vsftpd option “chroot_local_user=YES” the users get jailed to a certain directory (in our example to directories below “/srv/www/htdocs/webs”). We may want to circumvent this restriction for our own admins whereas for the customer’s users it shall hold and work. To define such an exception requires further vsftp options:


If “chroot_local_use” is set to “YES” then UIDs given (one per line) in the file “vsftpd.chroot_list” are NOT jailed to a chroot directory. In this case the file “/etc/vsftpd.chroot_list” defines exceptions from the chroot-rule. Note, however, that if you had set


the opposite would be true: In this case the file “/etc/vsftpd.chroot_list” defines users to be explicitly jailed!

So, now we have combined all our objectives:
We open FTP access when we need it, we grant access to a list of users with most of them jailed to a certain directory
and we grant access to all directories for selected admins.

Have much fun with vsftp on Opensuse!

vsftp unter Opensuse 12.2 und 12.3

Ich bin gerade in der Situation, für Entwicklungszwecke parallel zwei Web-Testserver aufsetzen zu müssen – einen unter Opensuse 12.2 und einen unter Opensuse 12.3. Entwickler sollen per FTP Files in Verzeichnisse unterhalb von


auf die Apache Testservern hochladen. Die dortigen Verzeichnisse sind “named virtual domains” des Webservers zugeordnet. Neu entwickelte PHP-Programme sollen unter diesen Domainen für unsere Kunden getestet werden.

Der jeweils dedizierte und einzige FTP-User auf diesen Systemen hatte natürlicherweise ein zunächst leeres Home-Verzeichnis


erhalten. Bzgl. der ihm zugeordneten Shell habe ich “/bin/false” definiert. Die Entwickler sollen sich über den FTP-Account auf dem Server-System nicht in eine Shell einloggen können.

Als FTP-Serverdienst wollte ich zur Abwechslung mal “vsftp” mit SSL/TLS [ftps] statt “sftp” aus der openssh-Suite aufsetzen. Dabei erlebte ich so einige Überraschungen, die vielleicht auch für andere interessant sind, die sich an vsftp heranwagen oder von früheren Opensuse-Versionen auf OS 12.3 upgraden wollen.

Sicherheit spielt in meinem Fall für die Testserver, die nur aus einem lokalen Netz zugänglich sind, zwar nicht eine essentielle Rolle, aber wenn man einen solchen Service aufsetzt, dann natürlich zur Übung gleich auf TLS-Basis.

Die wichtigsten Statements der “/etc/vsftp.conf” sehen daher wie folgt aus:

ftpd_banner= mysysb vsFTP Server

und abhängig von der Opensuse-Version:

seccomp_sandbox=NO [für Opensuse 12.3]

Wichtiger Hinweis:
Nach meiner Erfahrung ist es leider so, dass der letzte Parameter bei Opensuse 12.3 auf NO gesetzt werden muss. Das gilt nicht für Opensuse 12.2 und Opensuse 13.1. Dort sollte man den Standard nehmen bzw. das Statement ganz weglassen. Die aktuellen man-pages führen diesen Parameter gar nicht mehr auf !

Natürlich kann man sich über das “chroot_local_user=YES” und die Tatsache, dass nicht mehrere virtuelle User angelegt wurden, vielleicht streiten. Aber wir wollen ja keine userspezifischen Daten-Container aufbauen, sondern gemeinsam genutzte Web-Test-Domainen versorgen.

Nicht ganz unwichtig ist hier das Statement


das auch künftige andere User auf ein ganz bestimmtes Verzeichnis – hier ist das identisch mit dem Home-Verzeichnis des FTP-Users – einschränken würde.

Übrigens: Da der FTP-User sich ja sowieso nicht einloggen darf, kann
man den Owner und die Gruppe des Verzeichnisses in unserem Fall auch auf “root:root”, z.B. mit Mode 751, ändern.

# chown root.root /srv/www/htdocs/webs
# chmod 751 /srv/www/htdocs/webs

Man muss das aber nicht. Wichtig ist hingegen der Entzug der Schreibrechte für unseren FTP-User – auch wenn das zunächst paradox wirken mag. Letzteres ist aus Sicherheitsgründen wichtig. Sie die Anmerkungen weiter unten.

Ein weiterer Hinweis:
Konfiguriert man vsftp mittels YaST2, so wird für TLS unbedingt ein File zu einem DSA-Key gefordert. Die YaST-CA-Verwaltung legt aber Serverzertifikate RSA-basiert an. Ich helfe mir über diese Klippe dadurch weg, dass ich das pem-File des RSA-Keys angebe, danach dann die Datei “vsftp.conf” editiere und die Statements zum Zertifikats- und Key-File wie oben gezeigt auf “RSA” abändere:


Die Kombination “local_enable=YES” und “ssl_enable=YES” lässt keine unverschlüsselten Sitzungen mehr zu

Hat man SSL aktiviert, werden unverschlüsselte Sitzungen nicht mehr zugelassen, wenn man sich über einen lokalen, nicht-anonymen User authentifizieren will. Das erscheint völlig logisch. Und so wunderte ich mich nicht, dass beim Versuch einer unverschlüsselten Verbindung folgende Meldung in FTP-Clients, wie Filezilla, hochkommt:

Response: 530 Non-anonymous sessions must use encryption.
Error: Could not connect to server

Eine klare und verständliche Meldung. Also “Explizites TLS” für die gewünschte FTP-Verbindung anfordern ! In Filezilla kann man das sehr einfach bei der Definition seiner FTP-Server hinterlegen.

Der FTP-User darf keine Schreibrechte auf sein chroot-Verzeichnis haben

Eine erste, wenn auch nicht wirklich überraschende Erkenntnis unter OS 12.2 und 12.3 war, dass man im Falle von


aus Sicherheitsgründen gehindert wird, auf ein chroot-Verzeichnis eingeschränkt zu werden, auf dem der FTP-User Schreibrechte hat.

Aber Achtung: Das ist in unserem Beispiel das Verzeichnis aus dem Statement


Das wäre auch so, wenn der FTP-Account ein tieferliegendes Heimatverzeichnis hätte !
Das Verzeichnis aus dem “local-root”-Statement kann durchaus ein anderes als das Heimatverzeichnis des FTP-Users sein! Passt man hier nicht auf, kann es bzgl. erforderlicher Rechtesetzungen schon mal zu Missverständnissen und Fehlern kommen. Der zu authentifizierende FTP-User darf bei Benutzung von “local_root” keine Scheibrechte auf demjenigen Verzeichnis haben, das in diesem Statement angesprochen wird. Die Rechte bzgl. eines ggf. abweichenden Heimatverzeichnis ist bei gesetztem “local_root” zweitrangig !

Die Einschränkung bzgl. der Schreibrechte versteht man! Das ist übrigens schon seit der vsftp-Version 2.5.x so und ist u.a. auch bei der Einrichtung aktueller sftp-Varianten mit chroot-Definitionen zu beachten.

Man kann das Verweigern einer Verbindung zu einem beschreibbaren chroot-Verzeichnis unter aktuellen vsftp-Versionen auch nicht mehr wie früher durch irgendwelche zusätzlichen Parameter wie “allow_writeable_chroot=YES” umgehen. Was dann natürlich Konsequenzen für das Setup der Verzeichnisstruktur hat, die von außen per FTP zugänglich sein soll.

Das eigentliche Problem ist aber, dass man als vsftp-Unbedarfter ggf. nicht entfernte Schreibrechte auf dem chroot-Verzeichnis nicht unbedingt als die eigentliche Ursache von Fehlermeldungen erkennt ! Solche Rechte können z.B. auch über eine unglücklich gesetzte Gruppenzugehörigkeit
ins Spiel kommen. Genau das war bei mir der Fall.

Hat man nun unglücklicherweise bei der Einrichtung des FTP-Users

  • entweder Standardrechte auf seinem Heimatverzeichnis gesetzt und belassen,
  • oder bei der Zuordnung zu einer Gruppe Schreibrechte auf dem chroot-Verzeichnis übersehen,
  • oder nicht erkannt, dass es in der obigen Konfiguration um die Schreibrechte auf dem Verzeichnis aus dem “local_root”-Statement und nicht wirklich um das Heimatverzeichnis des FTP-Users geht,

so kann das unter bestimmten Umständen in Filezilla und unter OS 12.2 zu TLS-bezogenen Fehlermeldungen führen, was dann doch sehr missverständlich ist. Ich jedenfalls bekam beim Experimentieren mit sftp haufenweise TLS-Fehlermeldungen, die meist mit dem eigentlichen Problem – wie hier einer risikoreichen Zugangsberechtigung – im Kern gar nichts zu tun hatten und in die Irre führten. [Die Funktionstüchtigkeit seiner TLS-Einrichtung und seiner Zertifikate sollte man natürlich auch mal unabhängig von vsftp testen!]

Auf dem OS 12.3 erhielt ich dann aber nach einigen Experimenten in einer aktuellen Filezilla-Version die Meldung:

500 OOPS: vsftpd: refusing to run with writable root inside chroot ()

Die half dann wirklich weiter. Weiteren Aufschluss brachten folgender Artikel und die dortige Diskussion

sowie ein genereller Artikel zu Sicherheit im Zshg. mit chroot()

Hilfreich war zudem ein Blick in die Original-FAQ-Hinweise zum akt. vsftp-Packet in der Version 3.0.2 unter
aus der ich nachfolgend zitiere:

Q) Help! I’m getting the error message “refusing to run with writable root”.
A) vsftpd is protecting against dangerous configurations. The cause of this message is usually dodgy ownership of the ftp home directory. The home directory should NOT be owned by the ftp user itself. Neither should it be writable by the ftp user. A way to fix this is:
chown root ~ftp; chmod -w ~ftp
Another cause might be an attempt to use chroot_local_user without setting up the directory ownership properly.

Ok, das ist klar. Natürlich sollte ein FTP-User nicht an seinem Root-Verzeichnis herumpfuschen können. Das gilt, wie gesagt, auch für sftp-Installationen aus der openssh-Suite (s. etwa: http://www.techrepublic.com/blog/opensource/chroot-users-with-openssh-an-easier-way-to-confine-users-to-their-home-directories/229)

Also verändert man in Fällen, die meiner Konstellation vergleichbar sind, am besten die Owner und die Rechte auf dem local_root-Verzeichnis, wie oben beschrieben.

Ein weiteres interessantes Thema:

Q) Help! What are the security implications referred to in the “chroot_local_user” option?
A) Firstly note that other ftp daemons have the same implications. It is a
generic problem.

The problem isn’t too severe, but it is this: Some people have FTP user accounts which are not trusted to have full shell access. If these accounts can also upload files, there is a small risk. A bad user now has control of the filesystem root, which is their home directory. The ftp daemon might cause some config file to
be read – e.g. /etc/some_file. With chroot(), this file is now under the control of the user. vsftpd is careful in this area. But, the system’s libc might want to open locale config files or other settings…

OK, hieraus verstehe ich, dass User mit “Shell” = “/bin/false” unter gewissen Umständen zu einem Problem werden können. (Auf anderen als Opensuse Systemen muss man ggf. /bin/fale auch in die Datei /etc/shells aufnehmen).

Tatsächlich ist es mir in einigen ersten schnell hintereinander durchgeführten experimentellen Anläufen mit Filezilla unter OS 12.2 gelungen, Dateistrukturen oberhalb des chroot-Verzeichnisses zu sehen, die ich eigentlich nicht mehr hätte sehen dürfen. Ich hatte dabei zunächst TLS abgeschaltet und den FTP-User auf “/bin/false” gesetzt und keine chroot-Einschränkung vorgenommen. Danach bei laufender Filezilla-Sitzung “chroot_local_user=YES” auf dem Server gesetzt und den FTP-Service per “systemctl restart vsftp.service” neu gestartet. Die Filzilla-Sitzung wird dabei unterbrochen – man kann sie aber sofort restarten. Und dann geschehen manchmal die seltsamsten Dinge bzgl. der Anzeige des Dateibaums. Und man sieht, wie gesagt, ggf. Dinge, die man nun nicht mehr sehen sollte. Irgendwie waren dabei wohl Filezilla- und Server-Caches im Spiel. Ein Refresh in Filezilla führte nämlich jedesmal zur Reduktion der Filesystem-Darstellung.

Was immer man daraus schließen mag … ich sehe es als jedenfalls wichtig an, dass an an chroot-Konfigurationen nicht im lauenden Betrieb rumgebastelt wird, wenn nicht sichergestellt ist, dass dann alle potentiellen Zwischenspeicher geleert sind. Man muss halt den svftp-Service sauber aufsetzen und nicht im produktiven Betrieb an Berechtigungen rumbasteln. Zudem ist der oben diskutierte grundsätzliche Entzug der Ownerschip und der Schreibrechte am chroot-Verzeichnis auch hier von Bedeutung: Waren die Rechte von vornherein richtig, d.h. restriktiv gesetzt, traten die beobachteten Probleme mit der Sicht auf unerlaubte Verzeichnisbereiche erst gar nicht auf.

Konsequenz: Entzug der Schreibrechte

Man nimmt dem FTP-User und auch der Gruppe, der er zugeordnet ist, die Schreibrechte am Heimatverzeichnis. Hier “/srv/www/htdocs/webs” und legt darunter ein oder mehrere schreibbare Verzeichnisse an. In meinem Fall kein Problem. (Was aber machen Leute, die nach einem Upgrade vorhandene Verzeichnisstrukturen nicht umorganisieren können oder wollen ?)

Unter OS 12.2 lief das Ganze dann in meinem Beispiel auch ohne Problem mit der dortigen PAM, der vsftp-Version 3.0.2-3.4.1 und dem Kernel 3.4.6.

Identische vsftp-version Konfiguration wie unter OS 12.2 läuft nicht unter OS 12.3 und Kernel 3.7.10

Nachdem der vsftp-Server unter OS 12.2 dann endlich so lief, wie ich mir das wünschte, und die Rechte auf hochgeladene Verzeichnisse und Dateien per vsftp-umask, SGID-Bit und setfacl so erzeugt wurden, wie ich das für sinnvoll und notwendig befand, wollte ich die gleiche Konfiguration auch unter Opensuse 12.3 zum Laufen bringen.

Erstmal ging zu meinem Schrecken aber gar nichts. Hier ein Auszug aus der Filezilla-Kommunikation mit dem Server:

Status: TLS/SSL-Verbindung hergestellt.
Antwort: 331 Please specify the password.
Befehl: PASS *******
Antwort: 230 Login successful.
Befehl: SYST
Antwort: 215 UNIX Type: L8
Befehl: FEAT
Antwort: 211-Features:
Antwort: AUTH TLS
Antwort: EPRT
Antwort: EPSV
Antwort: MDTM
Antwort: PASV
Antwort: PBSZ
Antwort: PROT
Antwort: SIZE
Antwort: TVFS
Antwort: UTF8
Antwort: 211 End
Befehl: OPTS
Antwort: 200 Always in UTF8 mode.
Befehl: PBSZ 0
Antwort: 200 PBSZ set to 0.
Befehl: PROT P
Antwort: 200 PROT now Private.
Status: Verbunden
Status: Empfange Verzeichnisinhalt…
Befehl: CWD /
Antwort: 250 Directory successfully changed.
Befehl: PWD
Antwort: 257 “/”
Befehl: TYPE I
Antwort: 200 Switching to Binary mode.
Befehl: PASV
Fehler: GnuTLS error -15: Ein unerwartetes TLS-Paket wurde empfangen.
Fehler: Verbindung zum Server getrennt: ECONNABORTED – Connection aborted
Fehler: Verzeichnisinhalt konnte nicht empfangen werden

Nach etlichen Recherchen fand ich dann, dass ab Kernel 3.5.X wohl der Parameter zur seccomp sandbox


auf NO gesetzt werden muss, was ich allerdings für produktive Server etwas beunruhigend finde. Siehe auch:

Jedenfalls können wir mit der genannten Einstellung dann auch unter OS 12.3 auf den vsftp-Server zugreifen.

Problem mit syslog_enable=YES

Als ich dann jedoch


setzen wollte, kam die nächste Überraschung. In Filezilla taucht danach nämlich folgende Meldung auf :

Status: Connecting to…
Status: Connection established, waiting for welcome message…
Response: 500 OOPS: priv_sock_get_cmd
Error: Critical error
Error: Could not connect to server

Tja, und dafür habe ich keine Lösung gefunden als eben


Logging muss man dann eben anders machen. Kann ich aber mit leben ….

Ältere Filezilla-Versionen vertragen die neue Standardoption “require_ssl_reuse=NO” nicht

Bei Filezilla-Versionen 3.5.X kommt es zu Problemen mit der FTP-Verbindung, wenn


gesetzt ist. Das ist aber in den aktuellen vsftp-Versionen als “Default” der Fall. Hier hilft dann im Falle einer Fehlermeldung ein explizites :


oder man muss sich unter OS 12.3 die aktuellere Filezilla Version von folgendem Repository


installieren. Mit dieser neueren Filezilla-Version geht dann auch “require_ssl_reuse=YES”.
(Ergänzung 08.06.2013: Es geht zumindest besser. Gestern bekam ich aber auch mit der neuen Filezilla-Version bei einem längeren Transfer ein Problem.)


Ich verstehe das Bestreben der vsftp-Entwickler nach maximaler Sicherheit gut. Aber das sollte nicht zu so vielen Problemen mit aktuellen Distributionen führen. Die Doku dieser Distributionen muss diesbzgl. auch besser werden und die erforderlichen Einstellungen und potentiellen Probleme in den Release-Notes beschreiben.

Wenn ich mal meine Erfahrungen auf produktive Systeme übertrage, stelle ich mir allerdings die Situation als schlimm vor, die entsteht, wenn solche Systeme auf OS 12.3 mit 3.5-Kernels upgegraded werden. Das dann entstehende Desaster hat evtl. schon einige Admins in den Wahnsinn
getrieben. Es war auf Basis der Fehlermeldungen nämlich nicht immer so leicht, sich die richtigen Einstellungen zusammenzureimen. Nicht gerade Werbung für Opensource !

Abschließender Hinweis zu vsftp-Tests mit Änderungen der Credentials des FTP-Users auf LDAP-Servern

Ein abschließender Hinweis noch zu Experimenten mit Änderungen an den Shell-Zuordnungen oder an den Credentials des FTP-Users:

Ich hatte meinen FTP-User über einen separaten LDAP-Server konfiguriert. Unter Opensuse 12.3 kommt SSSD zum Einsatz. In der Standardkonfiguration hatte SSSD bei mir auf dem Server mit vsftp die Credentials gecacht. Dann kann es bei geänderten Passwörtern zu Problemen kommen, wenn der Remote-FTP-Client das neue und auf dem LDAP-Server auch geänderte Passwort benutzt, aber der vsftp-Server wegen des sssd-Chachings von dem neuen Passwort ggf. noch nichts mitbekommen hat!

In einer solchen Situation muss man die SSSD-Cache-Information, z.B. zu einem User, gezielt mittels des Kommandos

sss_cache -u USER

löschen. Unter USER ist die User-Id anzugeben.
(Das Thema der Verwendung gechachter Information durch SSSD hat mich beim Testen von Zugriffsberechtigungen für bestimmte vsftp-User mal kurzzeitig außer Fassung gebracht und mir gezeigt, das sssd-Caching auch mal ein substanzielles Problem darstellen kann !)

Zu anderen Varianten des sss_cache Kommados für das Purgen von Cache-Daten in bestimmten SSSD-Domainen sehe man in die man-Seiten und

Unter Opensuse muss man übrigens das Paket “sssd-tools” installieren, um “sss_cache” nutzen zu können.

Ergänzung 04.09.2013 zu Firewall-Einstellungen:
Wegen eines aktuellen Erlebnisses: Natürlich muss man auch die Firewalls sowohl auf dem Server als auch auf dem Client angemessen einstellen. So ist auf dem Server der Port 21 für die Clients zu öffnen – wie auch der Range der Ports > 1024, die für den passiven FTP-Austausch benutzt werden. Die entsprechenden Port-Festlegungen hat man in der “/etc/vsftp.conf” vorgenommen. Standardmäßig ist dort der Range


eingestellt. Aber natürlich kann ma auch einen anderen Range wählen. Man darf dann nur nicht vergessen, die Firewall(s) anzupasssen !

Ergänzung 07.11.2014 zum Parameter connect_from_port_20
Ein Leser hat mich darauf aufmerksam gemacht, dass die Einstellung


ein kleinen Sicherheitsvorteil bringen mag. Das wird ein wenig kontrovers diskutiert. Siehe z.B.:
In vielen vsftpd Installationsanweisungen im Internet findet man aber die Einstellung “NO”. Da ich in der NO-Einstellung auch keinen gravierenden Nachteil erkennen kann, habe ich die oben angegebenen Einstellungen entsprechend abgeändert.