Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
I have a problem with vsftpd (latest version available, 2.1.0pre3) SSL. I've configured it to a nonstandard port, 65440, disabled connect_from_port_20 and run it as a normal user, from home directory. I can't use the SSL feature, every time I connect, it only reaches the login process. After logging in, I get the following error (when data transfer would start for LIST command):
522 SSL connection failed; session reuse required
My vsftpd.conf looks like this
Code:
local_enable=NO
write_enable=YES
secure_email_list_enable=YES
email_password_file=/home/stringz/vsftpd/logins
# local_umask=022
dirmessage_enable=NO
vsftpd_log_file=/dev/null
xferlog_file=/dev/null
xferlog_enable=NO
connect_from_port_20=NO
idle_session_timeout=3600
data_connection_timeout=120
run_as_launching_user=YES
anonymous_enable=YES
anon_mkdir_write_enable=YES
anon_other_write_enable=YES
anon_upload_enable=YES
anon_world_readable_only=NO
async_abor_enable=YES
ascii_upload_enable=YES
ascii_download_enable=YES
ftpd_banner=Welcome!
# You may specify an explicit list of local users to chroot() to their home
# directory. If chroot_local_user is YES, then this list becomes a list of
# users to NOT chroot().
# chroot_list_enable=YES
# (default follows)
# chroot_list_file=/etc/vsftpd.chroot_list
ls_recurse_enable=NO
listen=YES
listen_address=<myipaddress>
listen_port=65440
listen_ipv6=NO
pasv_enable=YES
pasv_min_port=65441
pasv_max_port=65480
# chroot_local_user=YES
ssl_enable=YES
allow_anon_ssl=YES
force_local_data_ssl=NO
force_local_logins_ssl=YES
ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO
rsa_cert_file=/home/stringz/vsftpd/vsftpd.pem
The client side is a Total Commander 7.02, there hasn't been any problem with its SSL yet and this only occurs when trying to connect to my vsftpd.
What could be the problem?
I had exactly the same problem when setting up VSFTPD with SSL.
After a LOT of messing around I tracked it down to a problem with our firewall.
The firewall was running PIX which was inspecting the FTP traffic. The login was fine (running over port 21), but when it tried to transfer data (over the PASV port range) the firewall couldn't read the encrypted data and therefore couldn't open the correct PASV port.
Try temporarily putting the FTP server in your DMZ and see if it fixes the problem... If it does, you know you're on the right track!
I had exactly the same problem when setting up VSFTPD with SSL.
After a LOT of messing around I tracked it down to a problem with our firewall.
The firewall was running PIX which was inspecting the FTP traffic. The login was fine (running over port 21), but when it tried to transfer data (over the PASV port range) the firewall couldn't read the encrypted data and therefore couldn't open the correct PASV port.
Try temporarily putting the FTP server in your DMZ and see if it fixes the problem... If it does, you know you're on the right track!
Hope this is useful.
Hey, thanks for your answer. The client side had a firewall, I turned it off now for testing, but no success. There's no firewall at the server side, the iptables looks like this
Is it possible that vsftpd tries to open a port for secure data transfer below 1024 (e.g. 20 or something), because it can't because of Unix socket permissions (non-root).
Well it's obviously not the problem I experienced.
Your iptables look fine...
I found this on the web:
Quote:
Should the server not like the TLS negotiation then it will close the data port immediately and follow the 150 command with a 522 reply indicating that the TLS negotiation failed or was unacceptable.
Try using WinSCP to connect and crank up the logging, see if you can't find a more helpful error!
Unfortunately I can't do it with WinSCP. This would be a password-secured anonymous FTP (take a look at the config) that is used by more than 1 people without knowing each-other's passwords. In this case WinSCP would be unsecure, because it'd grant them full SSH access to my account. That's why I must stick to this kind of FTP solution.
When compiling vsftpd there is a parameter "tunable_require_ssl_reuse" in tunables.c file, this should be turned to '0' if u do not want to enable this option. In vsftpd.conf there is a parameter as well "require_ssl_reuse" which is by default set to YES, this should also be set to NO to disable this.
Restart vsftpd and see.
I had another wierd issue,I used Glub Tech ftp client to test ftps. Initially it would not let me logon via ftps.
But when I logged using ftp and then disconnected, I was able to logon via ftps as well.
In vsftpd.conf there is a parameter as well "require_ssl_reuse" which is by default set to YES, this should also be set to NO to disable this.
Hi That's solved my problem.thanks a lot.
before I set require_ssl_reuse=NO,
my client always said:
Error: Failed to retrieve directory listing
and server always said :
No SSL session reuse on data channel.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.