I occasionally run a local vsftp daemon on my development machine for testing. I don’t connect to it directly — it’s used to back up unit tests that need an FTP connection. No person connects to it, least of all me, and the scripts that do connect are looking at small, single-use directories.
I needed to test a new feature: FTPS, aka FTP with SSL (Not to be confused with SFTP, a very different beast.) Several of our vendors will be requiring it soon; frankly, I’m surprised they haven’t required it sooner. But I digress.
To start this phase of the project I needed to make sure that my local vsftp daemon supports FTPS so that I can run tests against it. So I edit /etc/vsftpd/vsftpd.conf to add some lines to my config, and restart:
rsa_cert_file=/etc/ssl/private/vsftpd.pem rsa_private_key_file=/etc/ssl/private/vsftpd.pem ssl_enable=YES
But Filezilla bombs with an opaque error message:
Status: Resolving address of localhost Status: Connecting to 127.0.0.1:21... Status: Connection established, waiting for welcome message... Status: Initializing TLS... Status: Verifying certificate... Status: TLS connection established. Status: Logged in Status: Retrieving directory listing... Command: PWD Response: 257 "/home/dad" is the current directory Command: TYPE I Response: 200 Switching to Binary mode. Command: PASV Response: 227 Entering Passive Mode (127,0,0,1,249,239). Command: LIST Response: 150 Here comes the directory listing. Error: GnuTLS error -15: An unexpected TLS packet was received. Error: Disconnected from server: ECONNABORTED - Connection aborted Error: Failed to retrieve directory listing
I clue in pretty quickly that “GnuTLS error -15: An unexpected TLS packet was received” is actually a red herring, so I drop the SSL from the connection and get a different error:
Response: 150 Here comes the directory listing. Error: Connection closed by server Error: Failed to retrieve directory listing
Huh, that’s not particularly helpful, shame on you Filezilla. I drop down further to a command-line FTP client to get the real error:
$ ftp localhost Connected to localhost. 220 (vsFTPd 3.0.3) Name (localhost:dad): 530 Please login with USER and PASS. 530 Please login with USER and PASS. SSL not available 331 Please specify the password. Password: 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. ftp> ls 200 PORT command successful. Consider using PASV. 150 Here comes the directory listing. 421 Service not available, remote server has closed connection ftp> quit
Ah. Now we’re getting somewhere.
A quick perusal turned up a stackexchange answer with the assertion that “the directory causing this behaviour had too many files in it (2,666).” My own directory is much smaller, about a hundred files. According to this bug report, however, the real maximum may be as few as 32 files. It’s not clear to me whether this is a kernel bug, a vsftpd bug, or just a bad interaction between recent kernels and vsftpd.
Happily, there is a work-around: add “seccomp_sandbox=NO” to vsftpd.conf.
Since vsftpd’s documentation is spare, and actual examples are hard to come by, here’s my working config:
listen=YES local_enable=YES write_enable=YES chroot_local_user=YES allow_writeable_chroot=YES seccomp_sandbox=NO ssl_enable=YES rsa_cert_file=/etc/ssl/private/vsftpd.pem rsa_private_key_file=/etc/ssl/private/vsftpd.pem
