VSFTPD FileZilla GnuTLS-fout -15 (onverwacht TLS-pakket werd ontvangen)

Ik had dezelfde fout na het PASS-commando in CENTOS 7. (GnuTLS-fout -15: er is een onverwacht TLS-pakket ontvangen.)

Mijn oplossing is de volgende:

Ik moest het volgende toevoegen aan vsftpd.conf:

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

Reacties

• Bedankt, voor mijn bestand /etc/vsftpd.conf voeg ik toe: user_sub_token = $ USER en heb nu niet de GNUTLS-fout -15 Op dit moment krijg ik een andere foutmelding: De gegevensverbinding kon niet tot stand worden gebracht: ECONNREFUSED – Verbinding geweigerd door server
• ik heb het opgelost in mijn bestand /etc/vsftpd.conf, ik heb dezelfde waarde geplaatst voor ” listen_address = 192.168.1.2 ” & ” pasv_address = 192.168.1.2 ” ik voeg dit laatste toe en werkt, ik heb het nodig: D
• In mijn geval heb ik had local_root naar een ontbrekende map – toen ik die variabele aanpaste, was fout 15 verdwenen.

Ik plaats dit antwoord in de hoop dat het in de toekomst iemand kan helpen, mogelijk mijzelf, aangezien ik dit probleem heb opgelost.

Ik had geen local_root in het /etc/vsftpd/vsftpd.conf -bestand correct ingesteld. De instelling wees naar een map, die niet bestond.

Wat via mij was, was dat ik de fout in het wachtwoordcommando in FileZilla zag, dus ik dacht dat het het wachtwoord niet leuk vond. Wat me in de goede richting zette, was dat ik de tijd nam om te onderzoeken waarom ik geen gedetailleerde logboeken ontving. Ik heb geen logboeken ontvangen. Toen ik eenmaal debug-logboeken begon te ontvangen, waar ik de FTP-protocollen zag, zag ik dat de FTP-server OK zei tegen het wachtwoord. Helaas was er geen enkele logging, maar ik kwam op de gedachte dat onderhandelen over de lokale root de volgende stap zou zijn na authenticatie van het wachtwoord. Ik had gelijk en dat leidde me naar het probleem.

Hier is het codefragment in het /etc/vsftpd/vsftpd.conf -bestand, dat de lokale root bevat.

# 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 

Hier is hoe ik eindelijk uitgebreide logboekregistratie heb ingeschakeld, hoewel ik dat nu zal uitschakelen om schijfruimte te besparen en de prestaties te verbeteren.

# 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, ik zou de opmerking als een bug beschouwen, aangezien xferlog_enable meer is dan het daadwerkelijke uploaden en downloaden van bestanden. Deze eigenschap schakelt ook logboekregistratie in. Google-onderzoek toont aan dat log_ftp_protocol=YES xferlog_enable=YES vereist.

Reacties

• Ik kwam net in dezelfde val terecht vanwege een spelfout. Het instellen van een geldige local_root-directory loste het probleem op.

Ik kreeg exact dezelfde foutmelding (fout: GnuTLS-fout -15: Een onverwacht TLS-pakket werd ontvangen.) En bonsde ongeveer een uur lang met mijn hoofd, maar toen kwam ik erachter dat de homedirectory van ftp-gebruikers die op het Gluster-volume stond, niet was aangekoppeld. Gemonteerd Gluster-volume en probleem opgelost.

Je moet schrijfbare chroot toestaan in je configuratiebestand:

sudo nano /etc/vsftpd.conf 

Voeg dan deze regel onderaan toe:

allow_writeable_chroot=YES 

En herstart de service:

sudo service vsftpd restart 

Vreemd genoeg kwam dit probleem naar voren toen ik probeerde ls na het inloggen.

Het bleek dat ik httpd had verwijderd ten gunste van nginx en de de map die ik gebruikte was eigendom van apache:apache en de gebruiker werd verwijderd toen ik httpd verwijderde. Ik chcon “d de mappen naar nginx:nginx en vervolgens de gebruiker in deze regels in mijn configuratiebestand vervangen: guest_username=nginx nopriv_user=nginx

Hopelijk helpt dit iemand daarbuiten, want de foutmeldingen waren helemaal niet nuttig.

Ik zou graag aan Ndianabasi willen toevoegen:

Wanneer je hebt:

allow_writeable_chroot=NO 

en je hebt chroot ingeschakeld, de Chroot-directory kan “niet schrijfbaar zijn voor de gebruiker waarmee je probeert in te loggen. Dit was mijn geval en dezelfde fout deed zich voor. Ik heb het (de root-dir) naar root: root gecapteerd en dat heeft het voor mij opgelost.

P.S. Ik heb gecontroleerd of ik de genoemde optie niet meer kan vinden in de man-paginas, maar het is mogelijk beschikbaar in oudere versies.

Reacties

• Als het antwoord is dat je schrijfbare chroot moet toestaan, hoe helpt dit iemand die dit probleem heeft?

controleer of de directory en de bovenliggende directories leesbaar en uitvoerbaar zijn voor de sftp-gebruiker.

Reacties

• Houd er rekening mee dat dit bepaalde vraag heeft een geaccepteerd antwoord , wat betekent dat hun probleem al was opgelost.
• bedankt, maar ik wilde alleen toevoegen hoe ik dit probleem heb opgelost in mijn geval. of vind je het nog steeds ongepast om iets toe te voegen?
• Ik noemde het bestaande antwoord omdat het klonk alsof dit specifieke probleem een heel specifiek antwoord had. Ben je exact dezelfde symptomen tegengekomen? niet, je kunt altijd & vragen om je eigen specifieke probleem te beantwoorden met uw specifieke antwoord.
• Ja, het had exact dezelfde symptomen.

Ik kan nog geen commentaar posten, dus dit is gedeeltelijk in reactie op Scotts commentaar en om het antwoord van Mr.Fantastic te verduidelijken …

Ik kwam hetzelfde probleem tegen en daarna wat vallen en opstaan ontdekte wat dit eigenlijk betekent en een betere oplossing (IMHO) dan het instellen van allow_writeable_chroot = YES.

Het betekent dat vsftpd de situatie zou moeten toestaan waarin de homedirectory van de gebruiker beschrijfbaar is voor die gebruiker . In plaats daarvan heb ik om veiligheidsredenen de permissies voor de root-map van de gebruiker gewijzigd in 555. Volgens een andere thread vermindert dit een “AANVAL VAN ROARING BEAST”.

In mijn geval was de oorspronkelijke setup: (777) drwxrwxrwx / home / ftpuser /

Door de gebruikersdirectory te veranderen in: (555) dr-xr-xr-x / home / ftpuser /

is de homedirectory van de gebruiker NIET beschrijfbaar door de gebruiker en dus hoefde ik de allow_writeable_chroot = YES niet te gebruiken. Dit is prima (en veiliger) voor mijn situatie, aangezien ik een vooraf ingestelde mapstructuur heb en niet wil dat de gebruiker nieuwe bestanden of mappen in hun hoofdmap maakt.

Ik kwam hier achter toen ik overschakelde de homedirectory naar / var / ftp via de local_root = parameter voor vsftpd en het werkte zonder allow_writeable_chroot = YES in te stellen. Deze map / var / ftp is (755) maar eigendom van root en dus niet schrijfbaar voor ftpuser.