vsftpd As FTPS Only, TLS 1.3, Chrooted Local Users

vsftpd

vsftpd from AppStream, made into an FTPS server: TLS required for every login and every transfer, TLS 1.3 only by default, the host's own accounts each locked into their home, passive data ports on a fixed range, no anonymous access, and every configuration checked by vsftpd itself before it lands. Original role for EL 10, live-tested with podman on Rocky Linux 10.

No download, and no version to pin. EL 10 packages vsftpd, so the role installs it by name and takes what the distribution ships: a security update arrives through dnf, not through a new release of this role. What the role owns is the configuration and the proof that the service works.

The distribution's unit, our configuration. The role installs vsftpd and openssl, writes the whole of /etc/vsftpd/vsftpd.conf (root 0600), and enables the unit the package ships: systemctl cat vsftpd shows the distribution's own unit. The listener is 127.0.0.1:21 by default; the live test reads the listening sockets and expects loopback only.

The package's own file is plain FTP on every interface. The stock vsftpd.conf listens on [::]:21 (listen_ipv6=YES, a dual-stack socket), lets local users log in and write, and configures no TLS at all, so a password crosses the network in clear (read in the package). The role writes the whole file instead: TLS forced for logins and for data - a plain-text login gets "530 Non-anonymous sessions must use encryption." and a data connection in clear "522 Data connections must be encrypted." (both measured) - TLS 1.3 only (a TLS 1.2 client is refused; vsftpd_tls12: true accepts it for older clients), anonymous off, active mode off, passive mode on a fixed port range. A data connection must resume the control connection's TLS session, which proves it comes from the client that logged in: one that does not gets "522 SSL connection failed: session reuse required" (measured; vsftpd_require_ssl_reuse: false lifts it for clients that cannot resume).

Local users, chrooted. Logins are the host's own accounts through PAM (/etc/pam.d/vsftpd requires a shell listed in /etc/shells), each locked into its home: the live test's user is still at / after cd ... vsftpd refuses a chroot root the user can write to, and the role keeps that refusal (it does not set allow_writeable_chroot), so a user's home belongs to root and the user writes in a directory inside it - tests/pre-converge.yml makes one that way. /etc/vsftpd/user_list keeps its stock deny list (root and the system accounts), and vsftpd_denied_users adds to it.

Checked before it lands, without a check flag. vsftpd has no test mode. Given the file and then -olisten=NO, it parses the whole file, loads the certificate and stops at its inetd check - "not configured for standalone, must be started from inetd" - binding nothing; any other message is the file's own error ("unrecognised variable in config file", "bad bool value", "SSL: cannot load RSA certificate" - measured). The order matters: vsftpd applies options in the order given, so with -olisten=NO BEFORE the file, the file's listen=YES wins and a real server starts - an earlier draft of this check did exactly that, and left a server holding port 21 that the real start then could not bind. /usr/local/libexec/iacbazaar-vsftpd-check is the template's validate.

A certificate is made if you bring none. Self-signed, P-256, 825 days, the common name from vsftpd_tls_common_name, the key root 0600. Point vsftpd_tls_cert and vsftpd_tls_key at your own and set vsftpd_tls_generate: false.

License

Commercial - IaC Bazaar EULA. (c) IaC Bazaar.