VSFTPD FileZilla GnuTLS feil -15 (uventet TLS-pakke ble mottatt)

Jeg hadde samme feil etter PASS-kommandoen i CENTOS 7. (GnuTLS-feil -15: En uventet TLS-pakke ble mottatt.)

Min løsning følger:

Jeg måtte legge til følgende i vsftpd.conf:

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

Kommentarer

• Takk, for filen /etc/vsftpd.conf legger jeg til: user_sub_token = $ USER og har nå ikke GNUTLS-feilen -15 Akkurat nå får jeg en annen feil: Datatilkoblingen kunne ikke opprettes: ECONNREFUSED – Tilkobling nektet av server
• jeg løste på filen min /etc/vsftpd.conf, jeg satte den samme verdien for » listen_address = 192.168.1.2 » & » pasv_address = 192.168.1.2 » jeg legger til dette siste og fungerer, jeg trenger det: D
• I mitt tilfelle hadde local_root pekt på en manglende katalog – da jeg endret variabelen, var feil 15 borte.

Jeg legger ut dette svaret i håp om at det kan hjelpe noen i fremtiden, muligens meg, ettersom jeg led av å løse dette problemet.

Jeg hadde ikke local_root i /etc/vsftpd/vsftpd.conf filen er riktig innstilt. Innstillingen pekte på en mappe som ikke eksisterte.

Det som var gjennom meg var at jeg så feilen på passordkommandoen i FileZilla, så jeg tenkte at den ikke likte passordet. Det som fikk meg til å tenke i riktig retning var at jeg tok meg tid til å undersøke hvorfor jeg ikke mottok detaljerte logger. Jeg fikk ingen logger. Når jeg begynte å motta feilsøkingslogger, der jeg så FTP-protokollene, så jeg at FTP-serveren sa OK til passordet. Dessverre var det ingen loggføringer av noe slag, men jeg kom over tanken på at forhandlinger om den lokale roten ville være neste tiltak etter autentisering av passordet. Jeg hadde rett, og det førte meg til problemet.

Her er kodefragmentet i /etc/vsftpd/vsftpd.conf -filen, som inneholder den lokale 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 

Slik slo jeg endelig på omfattende logging, selv om jeg vil slå det av nå for å spare diskplass og forbedre ytelsen.

# 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, jeg vil betrakte kommentaren som en feil, siden xferlog_enable er mer enn den faktiske opplastingen og nedlastingen av filer. Denne egenskapen slår også på logging. En Google-undersøkelse viser at log_ftp_protocol=YES krever xferlog_enable=YES.

Kommentarer

• Bare løp i samme felle på grunn av feilstaving. Å sette en gyldig local_root-katalog løste problemet.

Jeg møtte nøyaktig samme feil (Feil: GnuTLS-feil -15: En uventet TLS-pakke ble mottatt.) Og banket hodet i omtrent en time, men da fant jeg ut at ftp-brukerens hjemmekatalog som var på Gluster-volum ikke var montert. Montert Gluster-volum og problemet løst.

Du må tillate skrivbar chroot i konfigurasjonsfilen:

sudo nano /etc/vsftpd.conf 

Legg deretter til denne linjen nederst:

allow_writeable_chroot=YES 

Og start tjenesten på nytt:

sudo service vsftpd restart 

Merkelig for meg dukket dette problemet opp når jeg prøvde å ls etter innlogging.

Det viste seg å være at jeg hadde avinstallert httpd til fordel for nginx mappen jeg brukte var eid apache:apache og brukeren ble fjernet da jeg fjernet httpd. Jeg chcon «sendte katalogene til nginx:nginx og erstattet deretter brukeren i disse linjene i konfigurasjonsfilen min: guest_username=nginx nopriv_user=nginx

Forhåpentligvis hjelper dette noen der ute fordi feilmeldingene ikke var nyttige i det hele tatt.

Jeg vil gjerne legge til Ndianabasi:

Når du har:

allow_writeable_chroot=NO 

og du har aktivert chroot, kan Chroot-katalogen ikke skrives av brukeren du prøver å logge på som. Dette var saken min, og den samme feilen kom opp. Jeg kjente den (roten dir) til root: root og det fikset det for meg.

P.S. Jeg sjekket kan ikke finne det nevnte alternativet på mansidene lenger, men det kan være tilgjengelig i eldre versjoner.

Kommentarer

• Hvis svaret er at du må tillate skrivbar chroot, hvordan hjelper dette noen som har dette problemet?

Jeg kan ikke legge ut kommentarer ennå, så dette er delvis som svar på Scotts kommentar og for å avklare Mr.Fantastic sitt svar …

Jeg løp inn i det samme problemet og etter noen prøving og feiling fant ut hva dette faktisk betyr og en bedre løsning (IMHO) enn å sette allow_writeable_chroot = YES.

Det betyr at vsftpd skal tillate situasjonen der brukerens hjemmekatalog kan skrives av den brukeren . I stedet for av sikkerhetsmessige grunner endret jeg tillatelsene til brukerens rotmappe til 555. I følge en annen tråd reduserer dette et «ROARING BEAST ATTACK».

I mitt tilfelle var det originale oppsettet: (777) drwxrwxrwx / home / ftpuser /

Endring av brukerens katalog til: (555) dr-xr-xr-x / home / ftpuser /

gjorde at brukerens hjemmekatalog IKKE skrivbar av brukeren, og dermed måtte jeg ikke bruke allow_writeable_chroot = YES. Dette er greit (og sikrere) for min situasjon, da jeg har en forhåndsinnstilt katalogstruktur og ikke vil at brukeren skal lage nye filer eller kataloger i rotmappen sin uansett.

Jeg skjønte dette da jeg byttet hjemmekatalogen til / var / ftp via parameteren local_root = for vsftpd, og den fungerte uten å måtte angi allow_writeable_chroot = JA. Denne mappen / var / ftp er (755) men eies av root og kan derfor ikke skrives av ftpuser.