VSFTPD FileZilla GnuTLS errore -15 (è stato ricevuto un pacchetto TLS imprevisto)

Ho avuto lo stesso errore dopo il comando PASS in CENTOS 7. (Errore GnuTLS -15: è stato ricevuto un pacchetto TLS imprevisto.)

La mia soluzione è la seguente:

Ho dovuto aggiungere quanto segue a vsftpd.conf:

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

Commenti

• Grazie, per il mio file /etc/vsftpd.conf aggiungo: user_sub_token = $ USER e ora non ho lerrore GNUTLS -15 In questo momento ricevo un altro errore: Impossibile stabilire la connessione dati: ECONNREFUSED – Connessione rifiutata dal server
• Ho risolto il mio file /etc/vsftpd.conf, ho inserito lo stesso valore per ” listen_address = 192.168.1.2 ” & ” pasv_address = 192.168.1.2 ” aggiungo questultimo e funziona ne ho bisogno: D
• Nel mio caso io aveva local_root che puntava a una directory mancante: quando ho modificato quella variabile, lerrore 15 non cera più.

Sto postando questa risposta nella speranza che possa aiutare qualcuno in futuro, forse io, poiché ho sofferto per risolvere questo problema.

Non avevo local_root in il file /etc/vsftpd/vsftpd.conf impostato correttamente. Limpostazione puntava a una cartella, che non esisteva.

Ciò che mi ha colpito è stato che ho visto lerrore sul comando password in FileZilla, quindi ho pensato che non gli piacesse la password. Ciò che mi ha fatto pensare nella giusta direzione è stato il tempo per cercare il motivo per cui non ricevevo registri dettagliati. Non ho ricevuto log. Una volta che ho iniziato a ricevere i log di debug, dove ho visto i protocolli FTP, ho visto che il server FTP diceva OK alla password. Purtroppo, non cera alcun tipo di registrazione, ma mi sono imbattuto nel pensiero che la negoziazione della radice locale sarebbe stata la prossima linea di condotta dopo aver autenticato la password. Avevo ragione e questo mi ha portato al problema.

Ecco il frammento di codice nel file /etc/vsftpd/vsftpd.conf, contenente la radice 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 

Ecco come ho finalmente attivato la registrazione dettagliata, anche se ora la disattiverò per risparmiare spazio su disco e migliorare le prestazioni.

# 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, considererei il commento un bug, poiché xferlog_enable è più delleffettivo caricamento e download di file. Questa proprietà attiva anche la registrazione. Una ricerca di Google dimostra che log_ftp_protocol=YES richiede xferlog_enable=YES.

Commenti

• Sono appena incappato nella stessa trappola a causa di un errore di ortografia. Limpostazione di una directory local_root valida ha risolto il problema.

Ho riscontrato esattamente lo stesso errore (Errore: errore GnuTLS -15: È stato ricevuto un pacchetto TLS inaspettato.) E ho sbattuto la testa per unora, ma poi ho scoperto che la home directory degli utenti ftp che si trovava sul volume Gluster non era montata. Volume e problema Gluster montato risolti.

Devi consentire chroot scrivibile nel tuo file di configurazione:

sudo nano /etc/vsftpd.conf 

Quindi aggiungi questa riga in fondo:

allow_writeable_chroot=YES 

E riavvia il servizio:

sudo service vsftpd restart 

Stranamente per me questo problema si è verificato durante il tentativo di ls dopo laccesso.

Si è scoperto che avevo disinstallato httpd a favore di nginx e la cartella che stavo utilizzando era di proprietà di apache:apache e lutente è stato rimosso quando ho rimosso httpd. Ho chcon “d le directory a nginx:nginx e poi ho sostituito lutente in queste righe nel mio file di configurazione: guest_username=nginx nopriv_user=nginx

Si spera che questo aiuti qualcuno là fuori perché i messaggi di errore non sono stati affatto utili.

Vorrei aggiungere a Ndianabasi:

Quando hai:

allow_writeable_chroot=NO 

e hai chroot abilitato, la directory Chroot non può essere “scrivibile” dallutente con cui stai tentando di accedere. Questo era il mio caso e si è verificato lo stesso errore. Lho chown (la directory root) in root: root e questo lha risolto per me.

P.S. Ho controllato non riesco più a trovare lopzione menzionata nelle pagine man, ma potrebbe essere disponibile nelle versioni precedenti.

Commenti

• Se la risposta è che devi consentire chroot scrivibile, in che modo questo aiuta chiunque abbia questo problema?

controlla se la directory e le sue directory principali sono leggibili ed eseguibili per lutente sftp.

Commenti

• Tieni presente che questo una particolare domanda ha una risposta accettata , il che significa che il loro problema era già risolto.
• grazie, ma volevo solo aggiungere come ho risolto questo problema nel mio caso. o pensi che sia ancora inappropriato aggiungere qualcosa?
• Ho menzionato la risposta esistente perché sembrava che questo particolare problema avesse una risposta molto specifica. Hai riscontrato esattamente gli stessi sintomi? Se no, potresti sempre chiedere a & di rispondere al tuo problema specifico con la tua risposta specifica.
• Sì, aveva gli stessi identici sintomi.

Non posso ancora pubblicare commenti, quindi questo è in parte in risposta al commento di Scott e per chiarire la risposta di Mr.Fantastic …

Mi sono imbattuto in questo stesso problema e dopo alcuni tentativi ed errori hanno capito cosa significa effettivamente e una soluzione migliore (IMHO) rispetto allimpostazione di allow_writeable_chroot = YES.

Significa che vsftpd dovrebbe consentire la situazione in cui la directory home dellutente è scrivibile da quellutente . Invece per ragioni di sicurezza ho cambiato i permessi sulla cartella principale dellutente a 555. Secondo un altro thread questo mitiga un “ATTACCO DI BESTIA RUGGENTE”.

Nel mio caso la configurazione originale era: (777) drwxrwxrwx / home / ftpuser /

Cambiando la directory dellutente in: (555) dr-xr-xr-x / home / ftpuser /

ha reso la directory home dellutente NON scrivibile dallutente e quindi non ho dovuto utilizzare allow_writeable_chroot = YES. Questo va bene (e più sicuro) per la mia situazione in quanto ho una struttura di directory preimpostata e non voglio che lutente crei comunque nuovi file o directory nella sua cartella principale.

Lho capito quando ho cambiato la directory home in / var / ftp tramite il parametro local_root = per vsftpd e ha funzionato senza dover impostare allow_writeable_chroot = YES. Questa cartella / var / ftp è (755) ma di proprietà di root e quindi non può essere scritta da ftpuser.