VSFTPD FileZilla GnuTLS-fel -15 (oväntat TLS-paket mottogs)

Jag hade samma fel efter PASS-kommandot i CENTOS 7. (GnuTLS-fel -15: Ett oväntat TLS-paket mottogs.)

Min lösning följer:

Jag var tvungen att lägga till följande i vsftpd.conf:

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

Kommentarer

• Tack, för min fil /etc/vsftpd.conf lägger jag till: user_sub_token = $ USER och har nu inte GNUTLS-felet -15 Just nu får jag ett nytt fel: Dataanslutningen kunde inte upprättas: ECONNREFUSED – Anslutning nekad av servern
• jag löste i min fil /etc/vsftpd.conf, jag lägger samma värde för ” listen_address = 192.168.1.2 ” & ” pasv_address = 192.168.1.2 ” jag lägger till det här sist och fungerar jag behöver det: D
• I mitt fall hade local_root som pekade på en saknad katalog – när jag ändrade variabeln var fel 15 borta.

Jag lägger upp det här svaret i hopp om att det kan hjälpa någon i framtiden, eventuellt jag, eftersom jag led att lösa detta problem.

Jag hade inte local_root /etc/vsftpd/vsftpd.conf -filen är korrekt inställd. Inställningen pekade på en mapp som inte existerade.

Det som genom mig var att jag såg felet i lösenordskommandot i FileZilla, så jag trodde att det inte gillade lösenordet. Det som fick mig att tänka i rätt riktning var att jag tog mig tid att undersöka varför jag inte fick detaljerade loggar. Jag fick inga loggar. När jag började ta emot felsökningsloggar, där jag såg FTP-protokollen, såg jag att FTP-servern sa OK till lösenordet. Tyvärr fanns det ingen loggning av något slag, men jag kom över tanken att förhandla om den lokala roten skulle vara nästa åtgärd efter autentisering av lösenordet. Jag hade rätt och det ledde mig till problemet.

Här är kodfragmentet i filen /etc/vsftpd/vsftpd.conf, som innehåller den lokala roten.

# 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 

Så här aktiverade jag äntligen detaljerad loggning, men jag stänger av det nu för att spara diskutrymme och förbättra prestanda.

# 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, jag anser att kommentaren är ett fel, eftersom xferlog_enable är mer än den faktiska uppladdningen och nedladdningen av filer. Den här egenskapen aktiverar också loggning. En Google-undersökning visar att log_ftp_protocol=YES kräver xferlog_enable=YES.

Kommentarer

• Körde precis i samma fälla på grund av felstavning. Att ställa in en giltig local_root-katalog löste problemet.

Jag stod inför exakt samma fel (Fel: GnuTLS-fel -15: Ett oväntat TLS-paket togs emot.) Och slog mitt huvud i ungefär en timme men sedan tänkte jag att ftp-användarnas hemkatalog som var på Gluster-volymen inte var monterad. Monterad Gluster-volym och problemet löst.

Du måste tillåta skrivbar chroot i din konfigurationsfil:

sudo nano /etc/vsftpd.conf 

Lägg sedan till den här raden längst ner:

allow_writeable_chroot=YES 

Och starta om tjänsten:

sudo service vsftpd restart 

Konstigt för mig uppstod det här problemet när jag försökte ls efter inloggning.

Det visade sig att jag hade avinstallerat httpd till förmån för nginx mappen jag använde ägdes av apache:apache och användaren tog bort när jag tog bort httpd. Jag chcon ”skickade katalogerna till nginx:nginx och ersatte sedan användaren i dessa rader i min konfigurationsfil: guest_username=nginx nopriv_user=nginx

Förhoppningsvis hjälper det någon där ute eftersom felmeddelandena inte alls var till hjälp.

Jag vill lägga till Ndianabasi:

När du har:

allow_writeable_chroot=NO 

och du har aktiverat chroot, kan Chroot-katalogen inte skrivas av användaren du försöker logga in som. Detta var mitt fall och samma fel uppstod. Jag chowed det (roten dir) till root: root och det fixade det för mig.

P.S. Jag kollade kan inte hitta det nämnda alternativet på mansidorna längre, men det kan finnas i äldre versioner.

Kommentarer

• Om svaret är att du måste tillåta skrivbar chroot, hur hjälper detta någon som har detta problem?

Jag kan inte lägga upp kommentarer ännu så detta är delvis som svar på Scotts kommentar och för att klargöra Mr.Fantastics svar …

Jag stötte på samma problem och efter en del försök och fel fick reda på vad detta egentligen betyder och en bättre lösning (IMHO) än att ställa in allow_writeable_chroot = YES.

Det betyder att vsftpd bör tillåta situationen där användarens hemkatalog är skrivbar av den användaren . Istället av säkerhetsskäl ändrade jag behörigheterna för användarens rotmapp till 555. Enligt en annan tråd minskar detta en ”ROARING BEAST ATTACK”.

I mitt fall var den ursprungliga inställningen: (777) drwxrwxrwx / home / ftpuser /

Ändring av användarens katalog till: (555) dr-xr-xr-x / home / ftpuser /

gjorde att användarens hemkatalog INTE skrivbar av användaren och därmed behövde jag inte använda allow_writeable_chroot = YES. Det här är bra (och säkrare) för min situation eftersom jag har en förinställd katalogstruktur och inte vill att användaren ska skapa nya filer eller kataloger i sin rotmapp ändå.

Jag tänkte på det när jag bytte hemkatalogen till / var / ftp via parametern local_root = för vsftpd och det fungerade utan att behöva ställa in allow_writeable_chroot = JA. Den här mappen / var / ftp är (755) men ägs av root och kan därför inte skrivas av ftpuser.