4

I set up two new CentOS 7 boxes simultaneously, so the configurations should be identical, just different ip addresses and host names.

I installed VSFTPD and configured for passive ports. One box connects fine, no issues, however the second box continuously throws me this error:

GnuTLS error -15: An unexpected TLS packet was received.

Here is the debug FileZilla trace:

Status: Connecting to 192.168.20.68:21...
Status: Connection established, waiting for welcome message...
Trace:  CFtpControlSocket::OnReceive()
Response:   220 (vsFTPd 3.0.2)
Trace:  CFtpControlSocket::SendNextCommand()
Command:    AUTH TLS
Trace:  CFtpControlSocket::OnReceive()
Response:   234 Proceed with negotiation.
Status: Initializing TLS...
Trace:  CTlsSocket::Handshake()
Trace:  CTlsSocket::ContinueHandshake()
Trace:  CTlsSocket::OnSend()
Trace:  CTlsSocket::OnRead()
Trace:  CTlsSocket::ContinueHandshake()
Trace:  CTlsSocket::OnRead()
Trace:  CTlsSocket::ContinueHandshake()
Trace:  CTlsSocket::OnRead()
Trace:  CTlsSocket::ContinueHandshake()
Trace:  TLS Handshake successful
Trace:  Protocol: TLS1.2, Key exchange: ECDHE-RSA, Cipher: AES-256-GCM, MAC: AEAD
Status: Verifying certificate...
Status: TLS connection established.
Trace:  CFtpControlSocket::SendNextCommand()
Command:    USER datamover
Trace:  CTlsSocket::OnRead()
Trace:  CFtpControlSocket::OnReceive()
Response:   331 Please specify the password.
Trace:  CFtpControlSocket::SendNextCommand()
Command:    PASS *******
Trace:  CTlsSocket::OnRead()
Trace:  CTlsSocket::Failure(-15)
Error:  GnuTLS error -15: An unexpected TLS packet was received.
Trace:  CRealControlSocket::OnClose(106)
Trace:  CControlSocket::DoClose(64)
Trace:  CFtpControlSocket::ResetOperation(66)
Trace:  CControlSocket::ResetOperation(66)
Error:  Could not connect to server

The error is always right after the password check.

I know the problem IS NOT SELinux, as I disabled that. The problem is also not the firewall, as I tried disabling the Firewall Daemon (firewalld).

Here is the relevant portion of the /etc/vsftpd/vsftpd.conf file.

listen=YES
listen_ipv6=NO
pasv_enable=YES
pasv_max_port=10100
pasv_min_port=10090
pasv_address=192.168.20.88

ssl_enable=YES
allow_anon_ssl=NO
force_local_data_ssl=YES
force_local_logins_ssl=YES
ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO
ssl_ciphers=HIGH
require_ssl_reuse=NO

rsa_cert_file=/etc/ssl/private/vsftpd.pem
rsa_private_key_file=/etc/ssl/private/vsftpd.pem

I did a Google search but did not see any 15 error codes.

Thoughts?

4

I had same error after PASS command in CENTOS 7. (GnuTLS error -15: An unexpected TLS packet was received.)

My solution is following:

I had to add following to vsftpd.conf:

allow_writeable_chroot=YES

chroot_local_user=YES 
local_root=/ftphome/$USER 
user_sub_token=$USER
  • Thank you, for my file /etc/vsftpd.conf i add : user_sub_token=$USER and now not have the GNUTLS error -15 Right now i get another error : The data connection could not be established: ECONNREFUSED - Connection refused by server – inukaze Feb 20 '17 at 6:15
  • 1
    i solved on my file /etc/vsftpd.conf, i put the same value for "listen_address=192.168.1.2" & "pasv_address=192.168.1.2" i add this last and works i need it :D – inukaze Feb 20 '17 at 6:24
3

I am posting this answer in hopes that it might help someone in the future, possibly me, as I suffered solving this problem.

I did not have local_root in the /etc/vsftpd/vsftpd.conf file set properly. The setting pointed to a folder, which did not exist.

What through me was that I saw the failure on the password command in FileZilla, so I thought that it did not like the password. What got me thinking in the right direction was that I took the time to research why I was not receiving detailed logs. I received no logs. Once I started receiving debug logs, where I saw the FTP protocols, I saw that the FTP server said OK to the password. Sadly, there was no logging of any kind, but I came across the thought that negotiating the local root would be the next course of action after authenticating the password. I was right and that led me to the problem.

Here is the code fragment in the /etc/vsftpd/vsftpd.conf file, containing the local root.

# 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().
# (Warning! chroot'ing can be very dangerous. If using chroot, make sure that
# the user does not have write access to the top level directory within the
# chroot)
chroot_local_user=YES
#local_root=/mnt/raid1
local_root=/ftproot
#chroot_list_enable=YES
# (default follows)
#chroot_list_file=/etc/vsftpd/chroot_list

Here is how I finally turned on verbose logging, though I will turn that off now to conserve disk space and improve performance.

# Activate logging of uploads/downloads.
xferlog_enable=YES
#
# If you want, you can have your log file in standard ftpd xferlog format.
# Note that the default log file location is /var/log/xferlog in this case.
xferlog_std_format=NO
log_ftp_protocol=YES
#
# Activate logging of uploads/downloads.
xferlog_enable=YES

IMHO, I would consider the comment a bug, as xferlog_enable is more than the actual upload and download of files. This property also turns on logging. A Google research proves that log_ftp_protocol=YES requires xferlog_enable=YES.

  • Just ran into the same trap due to a misspelling. Setting a valid local_root directory solved the issue. – Johano Fierra Dec 20 '17 at 16:47
1

I faced exact same error(Error: GnuTLS error -15: An unexpected TLS packet was received.) and banged my head for like an hour but then i figured out that ftp users home directory which was on Gluster volume was not mounted. Mounted Gluster volume and issue resolved.

0

You need to allow writeable chroot in your configuration file:

sudo nano /etc/vsftpd.conf

Then add this line at the bottom:

allow_writeable_chroot=YES

And, restart the service:

sudo service vsftpd restart
0

Weirdly for me this issue cropped up when trying to ls after logging in.

It turned out to be that I had uninstalled httpd in favour of nginx and the folder I was using was owned apache:apache and the user got removed when I removed httpd. I chcon'd the directories to nginx:nginx and then replaced the user in these lines in my config file: guest_username=nginx nopriv_user=nginx

Hopefully this helps someone out there because the error messages weren't helpful at all.

0

I would like to add to Ndianabasi:

When you have:

allow_writeable_chroot=NO

and you have chroot enabled, the Chroot directory can't be writable by the user you're trying to log in as. This was my case and the same error came up. I chowned it (the root dir) to root:root and that fixed it for me.

P.S. I checked can't find the mentioned option in the man pages anymore, but it may be available in older versions.

  • If the answer is that you must allow writeable chroot, how does this help anybody who has this problem? – Scott May 2 at 22:05
0

check if the directory and its parent directories are readable and executable for the sftp user.

0

I can't post comments yet so this is partially in response to Scott's comment and to clarify Mr.Fantastic's answer ...


I ran into this same problem and after some trial and error figured out what this actually means and a better solution (IMHO) than setting allow_writeable_chroot=YES.

It means that vsftpd should allow the situation where the user's home directory is writeable by that user. Instead for security reasons I changed the permissions on the user's root folder to 555. According to another thread this mitigates a "ROARING BEAST ATTACK".

In my case the original setup was: (777) drwxrwxrwx /home/ftpuser/

Changing the user's directory to: (555) dr-xr-xr-x /home/ftpuser/

made the user's home directory NOT writeable by the user and thus I didn't have to use the allow_writeable_chroot=YES. This is fine (and more secure) for my situation as I have a preset directory structure and don't want the user making new files or directories in their root folder anyways.

I figured this out when I switched the home directory to /var/ftp via the local_root= parameter for vsftpd and it worked without having to set allow_writeable_chroot=YES. This folder /var/ftp is (755) but owned by root and thus not writeable by ftpuser.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.