Comment puis-je corriger cette erreur lorsque j'essaie de me connecter au serveur ftp sur filezila:
GnuTLS error -15: An unexpected TLS packet was received.
Et cette erreur sur le sublime plugin ftpsync:
ssl.SSLError: [SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:1515)
Voici mes paramètres vsftpd:
listen=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
nopriv_user=vsftpd
virtual_use_local_privs=YES
guest_enable=YES
user_sub_token=$USER
local_root=/var/www/$USER
chroot_local_user=YES
hide_ids=YES
guest_username=vsftpd
rsa_cert_file=/etc/ssl/private/vsftpd.pem
rsa_private_key_file=/etc/ssl/private/vsftpd.pem
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
require_ssl_reuse=NO
ssl_ciphers=HIGH
Il se peut que vous ayez une erreur qui n'a aucun rapport avec SSL.
ssl_enable=NO
)Ensuite, vous voyez probablement la vraie erreur.
C'est pourquoi la réponse Francisc IB n'a aucun rapport avec SSL.
la source
GnuTLS -15
erreur, et la désactivation de TLS donne des informations beaucoup plus appropriéesBizarrement pour moi, ce problème est apparu lors de la tentative de
ls
connexion.Il s'est avéré que j'avais désinstallé
httpd
en faveur denginx
et le dossier que j'utilisais appartenaitapache:apache
et l'utilisateur a été supprimé lorsque j'ai suppriméhttpd
. J'avaischcon
les répertoires ànginx:nginx
puis remplacé l'utilisateur dans ces lignes dans mon fichier de configuration:guest_username=nginx nopriv_user=nginx
J'espère que cela aide quelqu'un là-bas parce que les messages d'erreur n'étaient pas du tout utiles.
la source
J'ai trouvé tellement de réponses déroutantes. Je posterai un
qui a parfaitement fonctionné pour moi dans Ubuntu 18.04 en utilisant fileZilla en tant que client le 2019-09-04. Le FTPS est déployé dans une instance EC2 réglementée par un groupe de sécurité très strict qui n'autorise que l'accès à des IPS publics spécifiques.
la source
J'ai rencontré ce même problème. Un autre thread déconseille de définir allow_writeable_chroot = YES pour des raisons de sécurité, à savoir pour atténuer une "ATTAQUE DE BURAGE ROARING".
La définition de allow_writeable_chroot = YES signifie que vsftpd doit autoriser la situation dans laquelle le répertoire personnel de l'utilisateur est accessible en écriture par cet utilisateur. Au lieu de cela, pour des raisons de sécurité, j'ai modifié les autorisations sur le dossier racine de l'utilisateur de 777 à 555.
Cela a rendu le répertoire personnel de l'utilisateur NON inscriptible par l'utilisateur et je n'ai donc pas eu à utiliser le paramètre allow_writeable_chroot = YES . C'est bien (et plus sûr) pour ma situation car j'ai une structure de répertoires prédéfinie et je ne veux pas que l'utilisateur crée de nouveaux fichiers ou répertoires dans leur dossier racine de toute façon.
J'ai compris cela lorsque j'ai basculé le répertoire personnel vers / var / ftp via le paramètre local_root = [path] pour vsftpd et cela a fonctionné sans avoir à définir allow_writeable_chroot = YES . Ce dossier / var / ftp est (755) mais appartient à root et n'est donc pas accessible en écriture par ftpuser.
la source