11

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?

Sarah Weinberger
  • 662
  • 5
  • 13
  • 24

8 Answers8

12

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
Gyan
  • 121
  • 1
  • 3
  • 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 06: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 06:24
  • In my case I had local_root pointing to a missing directory - when I modified that variable, error 15 was gone. – Goran Usljebrka Apr 29 '20 at 15:17
  • Omg it worked. I just needed to add `allow_writeable_chroot=YES` – BozanicJosip Oct 21 '21 at 22:11
  • FWIW on version `3.0.3` of `vsftpd` there is no `allow_writeable_chroot` option. If your `local_root` is not writeable by the user running `vsftpd` then the service will not be able to access the directory and you will get that cryptic `GnuTLS error -15`. In my case, what I did was change the ownership of `local_root` to the user running `vsftpd` – mcwayliffe Mar 03 '22 at 19:39
5

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.

Sarah Weinberger
  • 662
  • 5
  • 13
  • 24
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.

xs2rashid
  • 111
  • 2
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
Ndianabasi
  • 101
  • 1
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.

Elven Spellmaker
  • 101
  • 2
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.

Rui F Ribeiro
  • 55,929
  • 26
  • 146
  • 227
Mr.Fantastic
  • 1
0

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

Rudger
  • 101
  • 2
  • Please note that this particular question has an [accepted answer](https://unix.stackexchange.com/a/270722/117549), meaning their problem was already solved. – Jeff Schaller Aug 28 '19 at 14:01
  • 1
    thanks, but i just wanted to add how i solved this problem in my case. or do you think its still inappropriate to add something? – Rudger Dec 17 '19 at 15:25
  • I mentioned the existing answer because it sounded like this particular problem had a very specific answer. Did you run across the exact same symptoms? If not, you could always ask & answer your own specific problem with your specific answer. – Jeff Schaller Dec 17 '19 at 15:27
  • 1
    Yes, it had the exact same symptons. – Rudger Dec 18 '19 at 15:20
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.

Daystrom75
  • 1