Erreur VSFTPD FileZilla GnuTLS -15 (un paquet TLS inattendu a été reçu)

Jai eu la même erreur après la commande PASS dans CENTOS 7. (Erreur GnuTLS -15: Un paquet TLS inattendu a été reçu.)

Ma solution est la suivante:

Jai dû ajouter ce qui suit à vsftpd.conf:

allow_writeable_chroot=YES chroot_local_user=YES local_root=/ftphome/$USER user_sub_token=$USER 

Commentaires

• Merci, pour mon fichier /etc/vsftpd.conf jajoute: user_sub_token = $ USER et maintenant pas lerreur GNUTLS -15 En ce moment jobtiens une autre erreur: La connexion de données na pas pu être établie: ECONNREFUSED – Connexion refusée par le serveur
• jai résolu sur mon fichier /etc/vsftpd.conf, jai mis la même valeur pour  » listen_address = 192.168.1.2  » &  » pasv_address = 192.168.1.2  » jajoute ce dernier et fonctionne jen ai besoin: D
• Dans mon cas, je avait local_root pointant vers un répertoire manquant – lorsque jai modifié cette variable, lerreur 15 avait disparu.

Je publie cette réponse dans lespoir que cela pourrait aider quelquun à lavenir, peut-être moi, car jai souffert de résoudre ce problème.

Je navais pas local_root dans le fichier /etc/vsftpd/vsftpd.conf correctement défini. Le paramètre indiquait un dossier, qui nexistait pas.

Ce qui ma traversé, cest que jai vu léchec de la commande de mot de passe dans FileZilla, donc jai pensé quil naimait pas le mot de passe. Ce qui ma fait réfléchir dans la bonne direction, cest que jai pris le temps de rechercher pourquoi je ne recevais pas de journaux détaillés. Je nai reçu aucun journal. Une fois que jai commencé à recevoir les journaux de débogage, où jai vu les protocoles FTP, jai vu que le serveur FTP disait OK au mot de passe. Malheureusement, il ny avait aucune journalisation daucune sorte, mais je suis tombé sur lidée que la négociation de la racine locale serait la prochaine étape après lauthentification du mot de passe. Javais raison et cela ma conduit au problème.

Voici le fragment de code dans le fichier /etc/vsftpd/vsftpd.conf, contenant la racine locale.

# 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 

Voici comment jai finalement activé la journalisation détaillée, bien que je la désactiverai maintenant pour économiser de lespace disque et améliorer les performances.

# 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 

À mon humble avis, je considérerais le commentaire comme un bogue, car xferlog_enable est plus que le téléchargement et le téléchargement réels de fichiers. Cette propriété active également la journalisation. Une recherche Google prouve que log_ftp_protocol=YES nécessite xferlog_enable=YES.

Commentaires

• Je viens de tomber dans le même piège en raison dune faute dorthographe. La définition dun répertoire racine_local valide a résolu le problème.

Jai rencontré exactement la même erreur (Erreur: erreur GnuTLS -15: Un paquet TLS inattendu a été reçu.) Et ma cogné la tête pendant environ une heure, mais jai ensuite compris que le répertoire personnel des utilisateurs ftp qui était sur le volume Gluster nétait pas monté. Volume et problème Gluster montés résolus.

Vous devez autoriser le chroot inscriptible dans votre fichier de configuration:

sudo nano /etc/vsftpd.conf 

Ensuite, ajoutez cette ligne en bas:

allow_writeable_chroot=YES 

Et, redémarrez le service:

sudo service vsftpd restart 

Curieusement pour moi, ce problème est survenu en essayant de ls après la connexion.

Il sest avéré que javais désinstallé httpd en faveur de nginx et le le dossier que jutilisais appartenait à apache:apache et lutilisateur a été supprimé lorsque jai supprimé httpd. Jai chcon « d les répertoires dans nginx:nginx puis jai remplacé lutilisateur dans ces lignes dans mon fichier de configuration: guest_username=nginx nopriv_user=nginx

Jespère que cela aidera quelquun là-bas parce que les messages derreur nétaient pas du tout utiles.

Je voudrais ajouter à Ndianabasi:

Lorsque vous avez:

allow_writeable_chroot=NO 

et que le chroot est activé, le répertoire Chroot ne peut « pas être accessible en écriture par lutilisateur avec lequel vous » essayez de vous connecter. Cétait mon cas et la même erreur sest produite. Je lai choisi (le répertoire racine) en root: root et cela ma corrigé.

P.S. Jai vérifié que « t ne trouve plus loption mentionnée dans les pages de manuel, mais elle peut être disponible dans les anciennes versions.

Commentaires

• Si la réponse est-ce que vous devez autoriser le chroot inscriptible, comment ceci aide-t-il quiconque a ce problème?

vérifier si le répertoire et ses répertoires parents sont lisibles et exécutables pour lutilisateur sftp.

Commentaires

• Veuillez noter que ceci une question particulière a une réponse acceptée , ce qui signifie que leur problème était déjà résolu.
• merci, mais je voulais juste ajouter comment jai résolu ce problème dans mon cas. ou pensez-vous quil est toujours inapproprié dajouter quelque chose?
• Jai mentionné la réponse existante, car il semblait que ce problème particulier avait une réponse très spécifique. Avez-vous rencontré exactement les mêmes symptômes? Si non, vous pouvez toujours demander à & de répondre à votre problème spécifique avec votre réponse spécifique.
• Oui, il présentait exactement les mêmes symptômes.

Je ne peux pas encore poster de commentaires donc cest en partie en réponse au commentaire de Scott et pour clarifier la réponse de Mr. Fantastic …

Jai rencontré ce même problème et après quelques essais et erreurs ont compris ce que cela signifie réellement et une meilleure solution (à mon humble avis) que de définir allow_writeable_chroot = YES.

Cela signifie que vsftpd devrait permettre la situation où le répertoire personnel de lutilisateur est accessible en écriture par cet utilisateur . Au lieu de cela, pour des raisons de sécurité, jai changé les autorisations sur le dossier racine de lutilisateur en 555. Selon un autre fil, cela atténue une « ROARING BEAST ATTACK ».

Dans mon cas, la configuration dorigine était: (777) drwxrwxrwx / home / ftpuser /

Changer le répertoire de lutilisateur en: (555) dr-xr-xr-x / home / ftpuser /

a rendu le répertoire personnel de lutilisateur NON inscriptible par lutilisateur et donc je nai pas eu à utiliser le allow_writeable_chroot = YES. Cest bien (et plus sûr) pour ma situation car jai une structure de répertoire prédéfinie et je ne veux pas que lutilisateur crée de toute façon de nouveaux fichiers ou répertoires dans son dossier racine.

Jai compris cela quand jai changé le répertoire personnel vers / var / ftp via le paramètre local_root = pour vsftpd et cela a fonctionné sans avoir à définir allow_writeable_chroot = YES. Ce dossier / var / ftp est (755) mais appartient à root et nest donc pas accessible en écriture par ftpuser.