Though there are a number of similar existing question/answers that reference vsftpd
and error code 530
, but they do not seem to be helpful in this case:
- vsftpd login error: 530
- VSFTPD 530 Login incorrect
- vsftp login errors 530 login incorrect
- 530 Login incorrect – vsftpd w/SSL (Not using PAM?)
- VSFTPD error 530 on fresh install
The situation is that a working vsftpd-2.2.2-24.el6.x86_64 instance on RHEL 6 (CentOS 6) is being migrated to an RHEL 7 (CentOS 7) server.
Of vsftpd
's configuration files, only these were modified:
/etc/vsftpd.chroot_list
to add local user names./etc/vsftpd/vsftpd.conf
The configuration is as follows and (*) indicates changes or additions to the distribution defaults:
anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
dirmessage_enable=YES
xferlog_enable=YES
connect_from_port_20=YES
xferlog_std_format=YES
ftpd_banner=Hello.
listen=YES (*)
listen_ipv6=NO (*)
pam_service_name=vsftpd
userlist_enable=YES
tcp_wrappers=YES
chroot_local_user=YES
chroot_list_enable=YES
chroot_list_file=/etc/vsftpd.chroot_list
dual_log_enable=YES
use_localtime=YES (*)
rsa_cert_file=/etc/httpd/conf/ssl/vsftpd.crt (*)
rsa_private_key_file=/etc/httpd/conf/ssl/vsftpd.key (*)
ssl_enable=YES (*)
allow_anon_ssl=NO (*)
force_local_data_ssl=NO (*)
force_local_logins_ssl=NO (*)
ssl_tlsv1=YES (*)
ssl_sslv2=NO (*)
ssl_sslv3=NO (*)
require_ssl_reuse=NO (*)
ssl_ciphers=HIGH (*)
ssl_tlsv1_1=YES (*)
ssl_tlsv1_2=YES (*)
allow_writeable_chroot=YES (*)
It is emphasized that the configuration was ported from a working vsftpd
instance.
After enabling and (re)starting the service with no reported isssues:
$ sudo systemctl status vsftpd
$ sudo systemctl enable vsftpd
$ sudo systemctl start vsftpd
$ sudo systemctl -l status vsftpd
an attempt was made to test the server:
$ cd ~ ; \
TEST="${HOME}/tmp/vsftpd_tst.`date +%Y%m%d%H%M`"; \
date >${TEST} ; \
curl -v -k -u ${USER} -ftp-ssl -T ${TEST} ftp://host.domain.tld/
Enter host password for user 'xxxx':
* STATE: INIT => CONNECT handle 0x600069c60; line 1418 (connection #-5000)
* Added connection 0. The cache now contains 1 members
* Trying host.domain.tld ...
* TCP_NODELAY set
* STATE: CONNECT => WAITCONNECT handle 0x600069c60; line 1470 (connection #0)
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
* Connected to host.domain.tld (x.x.x.x) port 21 (#0)
* STATE: WAITCONNECT => SENDPROTOCONNECT handle 0x600069c60; line 158 7 (connection #0)
* Marked for [keep alive]: FTP default
* FTP 0x60006fe40 (line 3113) state change from STOP to WAIT220
* STATE: SENDPROTOCONNECT => PROTOCONNECT handle 0x600069c60; line 16 01 (connection #0)
< 220 Hello.
> USER xxxx
* FTP 0x60006fe40 (line 801) state change from WAIT220 to USER
< 331 Please specify the password.
> PASS xxxxxxxxxxxx
* FTP 0x60006fe40 (line 2541) state change from USER to PASS
0 0 0 0 0 0 0 0 --:--:-- 0:00:03 --:--:-- 0
< 530 Login incorrect.
* Access denied: 530
* multi_done
* Marked for [closure]: FTP ended with bad error code
0 0 0 0 0 0 0 0 --:--:-- 0:00:03 --:--:-- 0
* Closing connection 0
* The cache now contains 0 members
curl: (67) Access denied: 530
The credentials are known and correct.
Best Answer
SELinux can be a candidate for suspicion in cases where a server has it enabled. In this case, both the old and new servers had SELinux installed, but the old server was not enforcing.
In the case, illustrated below, it appears that the locating the .crt and .key files in the
httpd
configuration space caused an issue:Unfortunately, in this case, while the suggestion was useful, it was not sufficient.
Failures continued, and
audit2allow
showed issues, but had no advice as to a specific command to run.This was resolved with: