vsftpd refuses connection

English Network/Internet
1

I have vsftpd running with virtual users on Tumbleweed. Since last weekend, logging in was suddenly no longer possible (530 Login incorrect).

I then installed vsftpd with vurtual users on Leap 42.3. Same problem.
On the Leap 42.3 I have all opportunities to experiment and test, I connect with ftp user@127.0.0.1.
Setting anonymous_enable=YES in /etc/vsftpd.conf made connecting as anonymous user possible.
Setting auth required pam_permit.so in /etc/pam.d/vsftpd (instead of auth required pam_pwdfile.so pwdfile=/etc/vsftpd.pw) did not make connecting possible (where I would expect any username/password to be accepted).

My conclusions so far are that the problem is not caused by pam_pwdfile.so and not by the firewall.
The /etc/vsftpd.conf looks like this:

write_enable=NO
dirmessage_enable=YES
hide_ids=YES
chmod_enable=NO
cmds_denied=RMD

local_enable=yes
local_umask=066
chroot_local_user=NO
secure_chroot_dir=/usr/share/empty
allow_writeable_chroot=YES

anonymous_enable=NO
anon_world_readable_only=YES
anon_upload_enable=NO
anon_mkdir_write_enable=NO
anon_other_write_enable=NO

guest_enable=YES
guest_username=virtual
user_config_dir=/etc/vsftpd_user_conf

xferlog_enable=YES
vsftpd_log_file=/var/log/vsftpd.log
log_ftp_protocol=no

connect_from_port_20=YES
pasv_enable=YES
pasv_min_port=40000
pasv_max_port=40500

pam_service_name=vsftpd
userlist_enable=YES
userlist_file=/etc/vsftpd.user_list

listen=YES
listen_port=21

ssl_enable=NO
anon_root=/usr/share/empty
ssl_sslv2=NO
ssl_sslv3=NO
ssl_tlsv1=YES

Any clues as to what the cause of the problems is?

2

First/Next step for troubleshooting probably should be to enable FTP logging…

In your posted vsftpd.conf,

Change the following line to “Yes”

xferlog_enable=YES
vsftpd_log_file=/var/log/vsftpd.log
log_ftp_protocol=no

Then read the log generated at the specified location.

When logs won’t give me the info I need,
My next step after that generally is to do a packet capture and analysis.

A verification,
Although you posted as a 42.3 problem, you say you are deployed on Tumbleweed, so this post really is likely a Tumbleweed issue.
A quick fix could be to roll back before the last update if you believe that your new problem is related to a TW update.

TSU

3

I put the log_ftp_protocol back to NO after I couldn’t find any clues there (and forgot to mention that in my first post).
This is what appears with log_ftp_protocol being YES:

Fri Apr 20 09:46:46 2018 [pid 24743] CONNECT: Client "127.0.0.1"
Fri Apr 20 09:46:46 2018 [pid 24743] FTP response: Client "127.0.0.1", "220 (vsFTPd 3.0.2)"
Fri Apr 20 09:46:46 2018 [pid 24743] FTP command: Client "127.0.0.1", "USER NIEDE"
Fri Apr 20 09:46:46 2018 [pid 24743] [NIEDE] FTP response: Client "127.0.0.1", "331 Please specify the password."
Fri Apr 20 09:46:49 2018 [pid 24743] [NIEDE] FTP command: Client "127.0.0.1", "PASS <password>"
Fri Apr 20 09:46:49 2018 [pid 24742] [NIEDE] FAIL LOGIN: Client "127.0.0.1"
Fri Apr 20 09:46:50 2018 [pid 24743] [NIEDE] FTP response: Client "127.0.0.1", "530 Login incorrect."
Fri Apr 20 09:46:52 2018 [pid 24743] FTP command: Client "127.0.0.1", "QUIT"
Fri Apr 20 09:46:52 2018 [pid 24743] FTP response: Client "127.0.0.1", "221 Goodbye."

I was very much in doubt whether to put Tumbleweed or Leap 42.3 in the thread. The problem occurs in both. As Tumbleweed is (slightly) less stable than Leap, I chose for Leap 42.3. Also, on the Leap 42.3 machine I can experiment freely.

A roll-back on the Tumbleweed machine failed. During the preparation for the roll-back, snapper decided to remove the ‘offending’ update. And with hindsight, it probably wouldn’t have helped as Leap 42.3 has the same problem.

4

First question I’d ask is if you’ve verified that connecting to 127.0.0.1 connects to the correct machine…
I don’t know if you’re connecting to the FTP server on the local machine, in a virtual machine or something else and sometimes for the person who does this the first time, he may be surprised at what has to be configured.
It’s usually better and more useful to connect using a network address (127.0.0.1 isn’t typically considered a network address).
Whatever machine you’re connecting to, be sure that the FTP server is bound to the interface with 127.0.0.1 assigned to it.

Next,
I’d test using the same OS for both client and server, and only after that works test using different OS for the clients.
Check the FTP and libcrypto versions used for each successful and unsuccessful connection.
Lastly, if perhaps only to verify that the problem is an encryption problem, I might also do a packet capture of an unsuccessful connection attempt.

The objective is to determine if the problem is related to the server or client, and then whether the problem is a crypto version on that machine.

TSU

5

127.0.0.1 is the correct machine, that is the local machine itself. Client and server are on the same machine. (The Tumbleweed machine has a typical network address, the Leap machine hasn’t, I using the leap machine for tests.)
So client and server share the same OS.

Check the FTP and libcrypto versions used for each successful and unsuccessful connection.
Lastly, if perhaps only to verify that the problem is an encryption problem, I might also do a packet capture of an unsuccessful connection attempt.

The objective is to determine if the problem is related to the server or client, and then whether the problem is a crypto version on that machine.

TSU

I don’t know what you mean with checking ‘FTP and libcrypto versions used for each successful and unsuccessful connection’ and what you mean with ‘do a packet capture of an unsuccessful connection attempt’.
I would like to check/do that and hopefully get closer to to the cause of the problem.

6

Just beware that the 127.0.0.1 interface is different than the network interface that remote machines need to access, and if your Server application isn’t bound to a working interface (for the connection you’re trying to set up), then you’ll get a failure. Been awhile since I’ve tested FTP on 127.0.0.1, but that often won’t work since a default install will assume that the Server is being set up for remote Clients.

The first tests you should always run is when you use the same OS (eg LEAP) for both Server and Client. If your machine is making a connection to itself, then that ordinarily shouldn’t be an issue, but still… Always run a “zypper up” to make sure both Server and Client apps are both updated and should be consistently the same (If for instance you installed the client long ago and only today installed the Server, even if both are Client/Server of the same app, you might have different versions).

Some additional things to try when troubleshooting…
Know whether you’re setting up Active or PASV connections, each mode works very differently and require opening up different FW ports. In fact, you appear to currently be configured for PASV. Try switching to “no” for Active FTP and try your FTP clients again.
Use different FTP clients to test, eg by default web browsers typically prefer Active FTP connections while you can specify either when using command line.
If you’re setting up in a protected environment, you can drop firewalls at first to avoid related complications.

For various reasons, if you find that Active works, you may want to keep that setting. PASV is an extra complication that’s more useful for enormous, heavy use by a multitude of simultaneous Users (very rare for anyone in this Forum).

TSU

7

To summarise the problem:
I have vsftpd installed on a Leap 42.3 machine and setup for virtual users with pam_pwdfile.
I use ftp in bash on the same machine to access the vfstpd server on localhost. I use a welcome banner to be sure I connect to the correct FTP server.

With ‘anonymous_enable=yes’ in /etc/vsftpd.conf, I can login:

Mon Apr 23 08:28:03 2018 [pid 8917] CONNECT: Client “127.0.0.1”
Mon Apr 23 08:28:03 2018 [pid 8917] FTP response: Client “127.0.0.1”, "220 “experimental FTP service on EPC353"”
Mon Apr 23 08:28:03 2018 [pid 8917] FTP command: Client “127.0.0.1”, “USER anonymous”
Mon Apr 23 08:28:03 2018 [pid 8917] [anonymous] FTP response: Client “127.0.0.1”, “331 Please specify the password.”
Mon Apr 23 08:28:11 2018 [pid 8917] [anonymous] FTP command: Client “127.0.0.1”, “PASS <password>”
Mon Apr 23 08:28:11 2018 [pid 8916] [ftp] OK LOGIN: Client “127.0.0.1”, anon password “rewt”
Mon Apr 23 08:28:11 2018 vsftpd [pid 8918]: “ftp” from “127.0.0.1”: cannot change directory:/ftpdataMon Apr 23 08:28:48 2018 [pid 8925] CONNECT: Client “1
27.0.0.1”
Mon Apr 23 08:28:48 2018 [pid 8925] FTP response: Client “127.0.0.1”, "220 “experimental FTP service on EPC353"”
Mon Apr 23 08:28:48 2018 [pid 8925] FTP command: Client “127.0.0.1”, “USER anonymous”
Mon Apr 23 08:28:48 2018 [pid 8925] [anonymous] FTP response: Client “127.0.0.1”, “331 Please specify the password.”
Mon Apr 23 08:28:51 2018 [pid 8925] [anonymous] FTP command: Client “127.0.0.1”, “PASS <password>”
Mon Apr 23 08:28:51 2018 [pid 8924] [ftp] OK LOGIN: Client “127.0.0.1”, anon password “rewt”
Mon Apr 23 08:28:51 2018 [pid 8926] [ftp] FTP response: Client “127.0.0.1”, “230 Login successful.”
Mon Apr 23 08:28:51 2018 [pid 8926] [ftp] FTP command: Client “127.0.0.1”, “SYST”
Mon Apr 23 08:28:51 2018 [pid 8926] [ftp] FTP response: Client “127.0.0.1”, “215 UNIX Type: L8”
Mon Apr 23 08:28:51 2018 [pid 8926] [ftp] FTP command: Client “127.0.0.1”, “FEAT”
Mon Apr 23 08:28:51 2018 [pid 8926] [ftp] FTP response: Client “127.0.0.1”, “211-Features:”
Mon Apr 23 08:28:51 2018 [pid 8926] [ftp] FTP response: Client “127.0.0.1”, " EPRT^M
"
Mon Apr 23 08:28:51 2018 [pid 8926] [ftp] FTP response: Client “127.0.0.1”, " EPSV^M
"
Mon Apr 23 08:28:51 2018 [pid 8926] [ftp] FTP response: Client “127.0.0.1”, " MDTM^M
"
Mon Apr 23 08:28:51 2018 [pid 8926] [ftp] FTP response: Client “127.0.0.1”, " PASV^M
"
Mon Apr 23 08:28:51 2018 [pid 8926] [ftp] FTP response: Client “127.0.0.1”, " REST STREAM^M
"
Mon Apr 23 08:28:51 2018 [pid 8926] [ftp] FTP response: Client “127.0.0.1”, " SIZE^M
"
Mon Apr 23 08:28:51 2018 [pid 8926] [ftp] FTP response: Client “127.0.0.1”, " TVFS^M
"
Mon Apr 23 08:28:51 2018 [pid 8926] [ftp] FTP response: Client “127.0.0.1”, " UTF8^M
"
Mon Apr 23 08:28:51 2018 [pid 8926] [ftp] FTP response: Client “127.0.0.1”, “211 End”
Mon Apr 23 08:28:51 2018 [pid 8926] [ftp] FTP command: Client “127.0.0.1”, “PWD”
Mon Apr 23 08:28:51 2018 [pid 8926] [ftp] FTP response: Client “127.0.0.1”, “257 “/””
Mon Apr 23 08:28:53 2018 [pid 8926] [ftp] FTP command: Client “127.0.0.1”, “EPSV”
Mon Apr 23 08:28:53 2018 [pid 8926] [ftp] FTP response: Client “127.0.0.1”, “229 Entering Extended Passive Mode (|||10072|).”
Mon Apr 23 08:28:53 2018 [pid 8926] [ftp] FTP command: Client “127.0.0.1”, “LIST”
Mon Apr 23 08:28:53 2018 [pid 8926] [ftp] FTP response: Client “127.0.0.1”, “150 Here comes the directory listing.”
Mon Apr 23 08:28:53 2018 [pid 8926] [ftp] FTP response: Client “127.0.0.1”, “226 Directory send OK.”
Mon Apr 23 08:28:56 2018 [pid 8926] [ftp] FTP command: Client “127.0.0.1”, “QUIT”
Mon Apr 23 08:28:56 2018 [pid 8926] [ftp] FTP response: Client “127.0.0.1”, “221 Goodbye.”

With ‘anonymous_enable=no’ in /etc/vsftpd.conf, and
‘auth required pam_permit.so’ in /etc/pam.d/vsftpd I can not login:

Mon Apr 23 08:29:47 2018 [pid 8944] CONNECT: Client “127.0.0.1”
Mon Apr 23 08:29:47 2018 [pid 8944] FTP response: Client “127.0.0.1”, "220 “experimental FTP service on EPC353"”
Mon Apr 23 08:29:47 2018 [pid 8944] FTP command: Client “127.0.0.1”, “USER NIEDE”
Mon Apr 23 08:29:47 2018 [pid 8944] [NIEDE] FTP response: Client “127.0.0.1”, “331 Please specify the password.”
Mon Apr 23 08:29:53 2018 [pid 8944] [NIEDE] FTP command: Client “127.0.0.1”, “PASS <password>”
Mon Apr 23 08:29:55 2018 [pid 8943] [NIEDE] FAIL LOGIN: Client “127.0.0.1”
Mon Apr 23 08:29:56 2018 [pid 8944] [NIEDE] FTP response: Client “127.0.0.1”, “530 Login incorrect.”
Mon Apr 23 08:29:59 2018 [pid 8944] FTP command: Client “127.0.0.1”, “QUIT”
Mon Apr 23 08:29:59 2018 [pid 8944] FTP response: Client “127.0.0.1”, “221 Goodbye.”
Mon Apr 23 08:30:06 2018 [pid 8947] FTP response: Client “127.0.0.1”, “221 Goodbye.”

With ‘anonymous_enable=no’ in /etc/vsftpd.conf, and
‘auth required pam_pwdfile.so debug pwdfile=/etc/vsftpd/.passwd’ in /etc/pam.d/vsftpd I can not login either.
I want this last setting to work.

My /etc/vsftpd.conf looks like this:

ftpd_banner="experimental FTP service on EPC353"

write_enable=NO
dirmessage_enable=YES
hide_ids=YES
chmod_enable=NO
cmds_denied=RMD

local_enable=yes
local_umask=066
chroot_local_user=NO
secure_chroot_dir=/usr/share/empty
allow_writeable_chroot=YES

anonymous_enable=NO
anon_root=/usr/share/empty
anon_world_readable_only=YES
anon_upload_enable=NO
anon_mkdir_write_enable=NO
anon_other_write_enable=NO

guest_enable=YES
guest_username=virtual
user_config_dir=/etc/vsftpd_user_conf

xferlog_enable=YES
vsftpd_log_file=/var/log/vsftpd.log
log_ftp_protocol=yes

connect_from_port_20=YES

pam_service_name=vsftpd
userlist_enable=YES
userlist_file=/etc/vsftpd.user_list

listen=YES
listen_port=21

ssl_enable=NO
ssl_sslv2=NO
ssl_sslv3=NO
ssl_tlsv1=no

I would like some advise on how to find the cause (and fix the problem).

8

Update:
Solved.
There was a nasty typo in /etc/pam.d/vsftpd (pam_permit.s0) which caused a lot of confusion.
Once I had corrected this, I could connect again on the Leap 42.3 machine.

On the Tumbleweed machine (from which the settings were copied onto the Leap 42.3 machine) I could connect (after correction) to localhost, but not from other machines.

Further investigations showed that the SuSEfirewall2 to firewalld conversion somehow had taken place without user interaction and with leaving vsftpd out of the allowed services.

Currently, all seems to be working fine again.

Tsu2, thank you for your suggestions. They didn’t directly lead me to the cause, but made me persevere in my search for the cause. At a certain moment /var/log/audit/audit.log showed that pam auth passed, but pam account failed and that told me where to look.

9

Congrats.
Unfortunately, typos will be the bane of all systems administrators forever and won’t ever likely be mitigated.

TSU