Am configurat două noi cutii CentOS 7 simultan, astfel încât configurațiile să fie identice, doar diferite adrese IP și nume de gazdă.
Am instalat VSFTPD și am configurat pentru porturi pasive. O casetă se conectează bine, fără probleme, cu toate acestea a doua casetă îmi aruncă în mod continuu această eroare:
GnuTLS error -15: An unexpected TLS packet was received. Iată urmărirea FileZilla pentru depanare:
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 Eroarea este întotdeauna imediat după verificarea parolei.
Știu că problema NU ESTE SELinux, deoarece am dezactivat asta. De asemenea, problema nu este firewall-ul, deoarece am încercat să dezactivez Daemon-ul Firewall (firewalld).
Iată porțiunea relevantă a fișierului /etc/vsftpd/vsftpd.conf.
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 Am făcut o căutare pe Google, dar nu am văzut 15 coduri de eroare.
Gânduri?
Răspuns
Am avut aceeași eroare după comanda PASS în CENTOS 7. (Eroare GnuTLS -15: A fost primit un pachet TLS neașteptat.)
Soluția mea este următoarea:
A trebuit să adaug următoarele la vsftpd.conf:
allow_writeable_chroot=YES chroot_local_user=YES local_root=/ftphome/$USER user_sub_token=$USER Comentarii
- Mulțumesc, pentru fișierul meu /etc/vsftpd.conf adaug: user_sub_token = $ USER și acum nu am eroarea GNUTLS -15 În acest moment primesc o altă eroare: Conexiunea de date nu a putut fi stabilită: ECONNREFUSED – Conexiunea refuzată de server
- Am rezolvat în fișierul meu /etc/vsftpd.conf, am pus aceeași valoare pentru ” listen_address = 192.168.1.2 ” & ” pasv_address = 192.168.1.2 ” adaug acest ultim și funcționează am nevoie de el: D
- În cazul meu I avea local_root care indica un director lipsă – când am modificat acea variabilă, eroarea 15. a dispărut.
Răspuns
Postez acest răspuns în speranța că ar putea ajuta pe cineva în viitor, eventual eu, deoarece am suferit rezolvarea acestei probleme.
Nu aveam local_root în fișierul /etc/vsftpd/vsftpd.conf setat corect. Setarea a indicat un dosar, care nu exista.
Ceea ce prin mine a fost că am văzut eșecul comenzii de parolă în FileZilla, așa că am crezut că nu-i place parola. Ceea ce m-a determinat să mă gândesc în direcția corectă a fost că mi-am făcut timp să cercetez de ce nu primeam jurnale detaliate. Nu am primit jurnale. Odată ce am început să primesc jurnale de depanare, unde am văzut protocoalele FTP, am văzut că serverul FTP a spus OK la parolă. Din păcate, nu a existat niciun fel de înregistrare, dar am venit cu gândul că negocierea rădăcinii locale va fi următorul curs de acțiune după autentificarea parolei. Am avut dreptate și asta m-a dus la problemă.
Iată fragmentul de cod din fișierul /etc/vsftpd/vsftpd.conf, care conține rădăcina locală.
# 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 Iată cum am activat în sfârșit înregistrarea detaliată, deși o voi dezactiva acum pentru a economisi spațiu pe disc și a îmbunătăți performanța.
# 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, aș considera comentariul o eroare, deoarece xferlog_enable este mai mult decât încărcarea și descărcarea efectivă a fișierelor. Această proprietate activează și înregistrarea. O cercetare realizată de Google demonstrează că log_ftp_protocol=YES necesită xferlog_enable=YES.
Comentarii
- Tocmai am nimerit în aceeași capcană din cauza unei greșeli de ortografie. Setarea unui director local_root valid a rezolvat problema.
Răspuns
Am întâmpinat exact aceeași eroare (Eroare: eroare GnuTLS -15: A fost primit un pachet neașteptat TLS.) Și mi-a lovit capul timp de o oră, dar apoi mi-am dat seama că directorul de acasă al utilizatorilor ftp care se afla pe volumul Gluster nu a fost montat. Volumul Gluster montat și problema rezolvate.
Răspuns
Trebuie să permiteți chrootul care poate fi scris în fișierul de configurare:
sudo nano /etc/vsftpd.conf Apoi adăugați această linie în partea de jos:
allow_writeable_chroot=YES Și reporniți serviciul:
sudo service vsftpd restart Răspuns
În mod ciudat, această problemă a apărut atunci când încerc să ls după conectare.
S-a dovedit că am dezinstalat httpd în favoarea nginx și a dosarul pe care îl foloseam era deținut apache:apache și utilizatorul a fost eliminat când am eliminat httpd. Am chcon „în directoare către nginx:nginx și apoi am înlocuit utilizatorul din aceste linii în fișierul meu de configurare: guest_username=nginx nopriv_user=nginx
Sperăm că acest lucru ajută pe cineva acolo, deoarece mesajele de eroare nu au fost deloc utile.
Răspuns
Aș dori să adaug la Ndianabasi:
Când aveți:
allow_writeable_chroot=NO și aveți chroot activat, directorul Chroot nu poate fi scris de către utilizatorul pe care încercați să vă conectați ca. Acesta a fost cazul meu și a apărut aceeași eroare. L-am înecat (dir. Rădăcină) pentru a rădăcină: rădăcină și asta l-a remediat.
P.S. Am bifat nu mai pot găsi opțiunea menționată în paginile manual, dar poate fi disponibilă în versiuni mai vechi.
Comentarii
- Dacă răspunsul este că trebuie să permiți un chroot care poate fi scris, cum ajută asta pe oricine are această problemă?
Răspunde
verificați dacă directorul și directoarele părinte ale acestuia sunt lizibile și executabile pentru utilizatorul sftp.
Comentarii
- Vă rugăm să rețineți că acest lucru o anumită întrebare are un răspuns acceptat , ceea ce înseamnă că problema lor a fost deja rezolvată.
- mulțumesc, dar am vrut doar să adaug cum am rezolvat această problemă în cazul meu. sau credeți că este încă nepotrivit să adăugați ceva?
- Am menționat răspunsul existent, deoarece părea că această problemă specială are un răspuns foarte specific. Ați întâmpinat exact aceleași simptome? Dacă nu, ați putea cere întotdeauna & să vă răspundeți la propria problemă specifică cu răspunsul dvs. specific.
- Da, avea exact aceleași simptome.
Răspuns
Nu pot încă să postez comentarii, deci acest lucru este parțial ca răspuns la comentariul lui Scott și pentru a clarifica răspunsul lui Mr.Fantastic …
Am dat peste aceeași problemă și după unele încercări și erori au dat seama ce înseamnă de fapt acest lucru și o soluție mai bună (IMHO) decât setarea allow_writeable_chroot = YES.
Înseamnă că vsftpd ar trebui să permită situația în care directorul de acasă al utilizatorului poate fi scris de către acel utilizator . În schimb, din motive de securitate, am schimbat permisiunile pentru folderul rădăcină al utilizatorului în 555. Potrivit unui alt fir, acest lucru atenuează un „ROARING BEAST ATTACK”.
În cazul meu, setarea inițială a fost: (777) drwxrwxrwx / home / ftpuser /
Schimbarea directorului utilizatorului în: (555) dr-xr-xr-x / home / ftpuser /
a făcut ca directorul de acasă al utilizatorului să NU scris de utilizator și, prin urmare, nu a trebuit să folosesc allow_writeable_chroot = YES. Acest lucru este în regulă (și mai sigur) pentru situația mea, deoarece am o structură de director presetată și nu vreau ca utilizatorul să creeze fișiere sau directoare noi în folderul rădăcină oricum.
Am aflat acest lucru când am trecut directorul principal la / var / ftp prin parametrul local_root = pentru vsftpd și a funcționat fără a fi necesar să setați allow_writeable_chroot = YES. Acest folder / var / ftp este (755), dar deținut de root și, prin urmare, nu poate fi scris de ftpuser.