Bug 922298

Summary: Logged-in user can't work with FTPS protocol
Product: [Fedora] Fedora Reporter: Matthew Saltzman <mjs>
Component: vsftpdAssignee: Jiri Skala <jskala>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: aglotov, jskala, jsynacek, nagy.martin
Target Milestone: ---Flags: jskala: needinfo?
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-04-27 08:10:21 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Normal ftp from client side (lftp)
none
Secure ftp from the client side (lftp)
none
Normal ftp from server side (strace)
none
Secure ftp from the server side (strace) none

Description Matthew Saltzman 2013-03-16 04:13:52 UTC 
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
Comment 1 Matthew Saltzman 2013-03-16 04:15:01 UTC 
Anonymous user can ls just fine.
Comment 2 Jiri Skala 2013-03-29 13:28:48 UTC 
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
Comment 3 Matthew Saltzman 2013-03-29 14:43:38 UTC 
Created attachment 718095 [details]
Normal ftp from client side (lftp)
Comment 4 Matthew Saltzman 2013-03-29 14:44:25 UTC 
Created attachment 718096 [details]
Secure ftp from the client side (lftp)
Comment 5 Matthew Saltzman 2013-03-29 14:45:44 UTC 
Created attachment 718097 [details]
Normal ftp from server side (strace)
Comment 6 Matthew Saltzman 2013-03-29 14:46:59 UTC 
Created attachment 718099 [details]
Secure ftp from the server side (strace)
Comment 7 Matthew Saltzman 2013-03-29 14:55:32 UTC 
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.
Comment 8 Jiri Skala 2013-04-26 12:33:25 UTC 
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
Comment 9 Matthew Saltzman 2013-04-26 18:42:17 UTC 
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.
Comment 10 Jiri Skala 2013-04-27 08:10:21 UTC 
> 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.