Description of problem: After logging into an FTPS session, the user can't perform actions such as 'ls'. The server might hang in various ways, but the action doesn't complete. Version-Release number of selected component (if applicable): vsftpd-3.0.2-1.fc18 How reproducible: Always Steps to Reproduce: 1. Set up certificate and enable FTPS (FTP over SSL) protocol on server 2. Connect with lftp or gftp client 3. Log in as user and issue 'ls' Actual results: Client hangs, for example: $ lftp jeeves lftp jeeves:~> user mjs Password: lftp mjs@jeeves:~> set verify-certificate off lftp mjs@jeeves:~> ls `ls' at 0 [Delaying before reconnect: 22] Expected results: Command completes, listing files in home directory (or whatever action is indicated) Additional info: Also fails in RHEL6 with vsftpd-2.2.2-11.el6_4.1. Relevant directives in /etc/vsftpd/vsftpd.conf: ssl_enable=YES allow_anon_ssl=YES force_local_data_ssl=YES force_local_logins_ssl=YES ssl_tlsv1=YES ssl_sslv2=NO ssl_sslv3=NO rsa_cert_file=/etc/vsftpd/vsftpd.pem rsa_private_key_file=/etc/vsftpd/vsftpd.pem
Anonymous user can ls just fine.
Hi, this works for me, I'm not able to reproduce it. Please, could you provide me following logs? A. output of $ lftp -d -u mjs jeeves B. if there is no clear root cause from previous output then please CHANGE temporary password of the user mjs and then do following steps: 1. # ps -FC vsftpd ; get the pid of process that has PPID=1 2. # strace -f -o <logname> -p <vsftpd_pid> 3. $ lftp -u mjs jeeves, ----> ls, stop and quit 4. stop strace and send me the log file Finally you can restore original password. The one will be contained in the log file so this is a reason of temporary change. Thanks, Jiri
Created attachment 718095 [details] Normal ftp from client side (lftp)
Created attachment 718096 [details] Secure ftp from the client side (lftp)
Created attachment 718097 [details] Normal ftp from server side (strace)
Created attachment 718099 [details] Secure ftp from the server side (strace)
Attached logs from both sides (different sessions on the client side and the server side, but the same actions in all four cases)--passwords and some filenames edited out. The secure session on the client side fails to connect for the listing exchange with a socket error. It uses a data port in quite a different range from the normal session. That was the only difference on the client side. Wasn't sure what to look for on the server side.
Hi, it works for me when the packet filtering is switched off or correctly configured. So I suppose your troubles are issued by packet filtering. You can verify it switching off packet filtering. Then you should extend your configuration following way: /etc/vsftpd/vsftpd.conf: pasv_min_port=40000 pasv_max_port=40100 /etc/sysconfig/iptables (of courese if you use INPUT chain directly or adjust): -A INPUT -p tcp -m state --state NEW --dport 40000:40100 -j ACCEPT service vsftpd restart service iptables restart The example is for RHEL-6. So you will replace 'service ...' by 'systemctl ...' and packet filtering depends on usage iptables/firewalld. Let me know if it works when packet filtering is switched off. Best regards Jiri
Yes, that works. It would be nice if this were documented someplace where it would be encountered when setting up vsftpd. One question: why does it work without the firewall setting for anonymous users? That is one reason I didn't think to suspect the firewall. Thanks.
> It would be nice if this were documented someplace where it would be encountered when setting up vsftpd. There is a little remark (I agree a bit unclear) in vsftpd.conf man page: pasv_max_port The maximum port to allocate for PASV style data connections. Can be used to specify a narrow port range to assist firewalling. as well as here https://docs.fedoraproject.org/en-US/Fedora/16/html/System_Administrators_Guide/s2-ftp-vsftpd-conf.html You are right this should be improved. > why does it work without the firewall setting for anonymous users? The anonymous doesn't work too when the packet filtering isn't set correctly. I guess it works for you because your's anonymous connection doesn't use ssl. Try using lftp with following setting: set ftp:ssl-allow-anonymous yes set ftp:ssl-protect-data yes Closing this bug.