VSFTPD FileZilla GnuTLS fejl -15 (uventet TLS-pakke blev modtaget)

Jeg havde den samme fejl efter PASS-kommandoen i CENTOS 7. (GnuTLS-fejl -15: En uventet TLS-pakke blev modtaget.)

Min løsning følger:

Jeg måtte tilføje følgende til vsftpd.conf:

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

Kommentarer

• Tak, for min fil /etc/vsftpd.conf tilføjer jeg: user_sub_token = $ USER og har nu ikke GNUTLS-fejlen -15 Lige nu får jeg endnu en fejl: Dataforbindelsen kunne ikke oprettes: ECONNREFUSED – Forbindelse nægtet af serveren
• jeg løste på min fil /etc/vsftpd.conf, jeg satte den samme værdi for ” listen_address = 192.168.1.2 ” & ” pasv_address = 192.168.1.2 ” Jeg tilføjer dette sidste og fungerer, jeg har brug for det: D
• I mit tilfælde havde local_root peget på en manglende mappe – da jeg ændrede variablen, var fejl 15 væk.

Jeg sender dette svar i håb om, at det kan hjælpe nogen i fremtiden, muligvis mig, da jeg led med at løse dette problem.

Jeg havde ikke local_root i /etc/vsftpd/vsftpd.conf -fil er indstillet korrekt. Indstillingen pegede på en mappe, som ikke eksisterede.

Hvad gennem mig var, at jeg så fejlen på kommandoen password i FileZilla, så jeg troede, at den ikke kunne lide passwordet. Hvad fik mig til at tænke i den rigtige retning var, at jeg tog mig tid til at undersøge, hvorfor jeg ikke modtog detaljerede logfiler. Jeg modtog ingen logfiler. Når jeg begyndte at modtage fejlretningslogfiler, hvor jeg så FTP-protokollerne, så jeg, at FTP-serveren sagde OK til adgangskoden. Desværre var der ingen logning af nogen art, men jeg stødte på tanken om, at forhandling om den lokale rod ville være det næste handlingsforløb efter godkendelse af adgangskoden. Jeg havde ret, og det førte mig til problemet.

Her er kodefragmentet i /etc/vsftpd/vsftpd.conf -filen, der indeholder den lokale rod.

# 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ådan har jeg endelig slået til detaljeret logning, selvom jeg vil slå det fra nu for at spare diskplads og forbedre ydeevnen.

# 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 betragter kommentaren som en fejl, da xferlog_enable er mere end den egentlige upload og download af filer. Denne egenskab aktiverer også logning. En Google-forskning viser, at log_ftp_protocol=YES kræver xferlog_enable=YES.

Kommentarer

• Løb lige i samme fælde på grund af stavefejl. Indstilling af en gyldig local_root-mappe løste problemet.

Jeg stod over for nøjagtig samme fejl (Fejl: GnuTLS-fejl -15: En uventet TLS-pakke blev modtaget.) Og bankede i hovedet i en time, men så regnede jeg med, at ftp-brugernes hjemmekatalog, der var på Gluster-lydstyrken, ikke var monteret. Monteret Gluster-volumen og problem løst.

Du skal tillade skrivbar chroot i din konfigurationsfil:

sudo nano /etc/vsftpd.conf 

Tilføj derefter denne linje i bunden:

allow_writeable_chroot=YES 

Og genstart tjenesten:

sudo service vsftpd restart 

Underligt for mig dukkede dette spørgsmål op, når jeg forsøgte at ls efter login.

Det viste sig at være, at jeg havde afinstalleret httpd til fordel for nginx og mappen, jeg brugte, var ejet apache:apache, og brugeren blev fjernet, da jeg fjernede httpd. Jeg chcon “tog mapperne til nginx:nginx og erstattede derefter brugeren i disse linjer i min konfigurationsfil: guest_username=nginx nopriv_user=nginx

Forhåbentlig hjælper dette nogen derude, fordi fejlmeddelelserne slet ikke var nyttige.

Jeg vil gerne tilføje til Ndianabasi:

Når du har:

allow_writeable_chroot=NO 

og du har chroot aktiveret, kan Chroot-biblioteket ikke skrives af den bruger, du prøver at logge på som. Dette var min sag, og den samme fejl opstod. Jeg chowed det (root dir) til root: root og det fik det til mig.

P.S. Jeg kontrollerede kan ikke finde den nævnte mulighed på mandsiderne længere, men den kan muligvis være tilgængelig i ældre versioner.

Kommentarer

• Hvis svaret er, at du skal tillade skrivbar chroot, hvordan hjælper dette nogen, der har dette problem?

Jeg kan ikke sende kommentarer endnu, så dette er delvist som svar på Scotts kommentar og for at afklare Mr.Fantastics svar …

Jeg løb ind i det samme problem og efter nogle forsøg og fejl fandt ud af, hvad dette faktisk betyder, og en bedre løsning (IMHO) end at indstille allow_writeable_chroot = YES.

Det betyder, at vsftpd skal tillade den situation, hvor brugerens hjemmekatalog kan skrives af den bruger . I stedet for af sikkerhedsmæssige årsager ændrede jeg tilladelserne til brugerens rodmappe til 555. Ifølge en anden tråd formindsker dette en “BULLENDE BEAST ATTACK”.

I mit tilfælde var den originale opsætning: (777) drwxrwxrwx / home / ftpuser /

Ændring af brugerens katalog til: (555) dr-xr-xr-x / home / ftpuser /

gjorde brugerens hjemmekatalog IKKE skrivbar af brugeren, og derfor behøvede jeg ikke at bruge allow_writeable_chroot = YES. Dette er fint (og mere sikkert) for min situation, da jeg har en forudindstillet bibliotekstruktur og ikke ønsker, at brugeren opretter nye filer eller mapper i deres rodmappe under alle omstændigheder.

Jeg fandt ud af det, da jeg skiftede hjemmekataloget til / var / ftp via parameteren local_root = til vsftpd, og det fungerede uden at skulle indstille allow_writeable_chroot = JA. Denne mappe / var / ftp er (755) men ejes af root og kan derfor ikke skrives af ftpuser.