VSFTPD FileZilla GnuTLS -virhe -15 (odottamaton TLS-paketti vastaanotettiin)

Minulla oli sama virhe PASS-komennon jälkeen CENTOS 7: ssä. (GnuTLS-virhe -15: Odottamaton TLS-paketti vastaanotettiin.)

Ratkaisuni on seuraava:

Minun täytyi lisätä seuraava tiedosto vsftpd.conf-tiedostoon:

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

kommentit

• Kiitos, tiedostostani /etc/vsftpd.conf lisäin: user_sub_token = $ USER ja nyt ei ole GNUTLS-virhettä -15 Saan nyt toisen virheen: Datayhteyttä ei voitu muodostaa: ECONNREFUSED – Palvelin hylkäsi yhteyden
• olen ratkaissut tiedostoni /etc/vsftpd.conf, laitoin saman arvon ” listen_address = 192.168.1.2 ” & ” pasv_address = 192.168.1.2 ” lisää tämä viimeinen ja toimii tarvitsen sitä: D
• Minun tapauksessani minä oli local_root osoittamaan puuttuvaan hakemistoon – kun muokkain muuttujaa, virhe 15 oli poissa.

Lähetän tämän vastauksen siinä toivossa, että se voisi auttaa jotakuta tulevaisuudessa, mahdollisesti minua, koska kärsin ongelman ratkaisemisessa.

Minulla ei ollut local_root /etc/vsftpd/vsftpd.conf -tiedosto on asetettu oikein. Asetus osoitti kansioon, jota ei ollut.

Minun kauttani näki FileZillan salasanakomennon epäonnistumisen, joten ajattelin, että se ei pitänyt salasanasta. Minun sai ajattelemaan oikeaan suuntaan se, että käytin aikaa tutkia, miksi en saanut yksityiskohtaisia lokeja. En saanut lokia. Kun aloin vastaanottaa virheenkorjauslokeja, joissa näin FTP-protokollat, huomasin, että FTP-palvelin sanoi OK salasanalle. Valitettavasti ei tapahtunut minkäänlaista kirjaamista, mutta törmäsin ajatukseen, että paikallisen juuren neuvotteleminen olisi seuraava toimintatapa salasanan todentamisen jälkeen. Olin oikeassa ja se johti minut ongelmaan.

Tässä on koodinpätkä /etc/vsftpd/vsftpd.conf -tiedostossa, joka sisältää paikallisen juuren.

# 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 

Näin otin vihdoin käyttöön tarkan kirjaamisen, vaikka sammutan sen nyt levytilan säästämiseksi ja suorituskyvyn parantamiseksi.

# 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, pidän kommenttia virheenä, koska xferlog_enable on enemmän kuin varsinainen tiedostojen lataaminen ja lataaminen. Tämä ominaisuus ottaa käyttöön myös puunkorjuun. Google-tutkimus osoittaa, että log_ftp_protocol=YES vaatii xferlog_enable=YES.

Kommentit

• Juoksin juuri samaan ansaan kirjoitusvirheen vuoksi. Kelvollisen local_root-hakemiston asettaminen ratkaisi ongelman.

Kohtasin täsmälleen saman virheen (Virhe: GnuTLS-virhe -15: Odottamaton TLS-paketti vastaanotettiin.) Ja löi päätäni noin tunnin ajan, mutta sitten huomasin, että Gluster-levyllä olevaa ftp-käyttäjien kotihakemistoa ei ollut asennettu. Asennettu Gluster-äänenvoimakkuus ja ongelma ratkaistu.

Sinun on sallittava kirjoitettava chroot määritystiedostossasi:

sudo nano /etc/vsftpd.conf 

Lisää sitten tämä rivi alareunaan:

allow_writeable_chroot=YES 

Ja käynnistä palvelu uudelleen:

sudo service vsftpd restart 

Minulle oudosti tämä ongelma rajautui yrittäessäni ls kirjautumisen jälkeen.

Osoittautui, että olin poistanut httpd asennuksen nginx ja Käyttämäni kansio oli omistuksessa apache:apache ja käyttäjä poistettiin, kun poistin httpd. chcon ”d hakemistot nginx:nginx ja korvasin käyttäjän sitten näillä riveillä määritystiedostossani: guest_username=nginx nopriv_user=nginx

Toivottavasti tämä auttaa joku siellä, koska virheilmoitukset eivät olleet lainkaan hyödyllisiä.

Haluan lisätä Ndianabasiin:

Kun sinulla on:

allow_writeable_chroot=NO 

ja sinulla on chroot-toiminto, Chroot-hakemistoa ei voi kirjoittaa käyttäjä, jolla yrität kirjautua. Tämä oli minun tapaukseni ja sama virhe tuli esiin. Näkin sen (juurihakemisto) root: rootiksi ja se korjasi sen minulle.

P.S. Tarkistin, että mainittua vaihtoehtoa ei enää löydy man-sivuilta, mutta se voi olla saatavilla vanhemmissa versioissa.

Kommentit

• Jos vastaus on, että sinun on sallittava kirjoitettava chroot, miten tämä auttaa ketään, jolla on tämä ongelma?

En voi vielä lähettää kommentteja, joten tämä on osittain vastaus Scottin kommenttiin ja Mr.Fantasticin vastauksen selventämiseksi …

törmäsin samaan ongelmaan ja Jotkut kokeilut ja erehdykset selvittivät, mitä tämä todella tarkoittaa, ja parempi ratkaisu (IMHO) kuin allow_writeable_chroot = YES.

Se tarkoittaa, että vsftpd: n pitäisi sallia tilanne, jossa kyseinen käyttäjä voi kirjoittaa käyttäjän kotihakemiston. . Sen sijaan muutin turvallisuussyistä käyttäjän juurikansioiden oikeuksiksi 555. Toisen säikeen mukaan tämä lieventää ”ROARING BEAST Attack” -ohjelmaa.

Minun tapauksessani alkuperäinen asetus oli: (777) drwxrwxrwx / home / ftpuser /

Käyttäjän hakemiston vaihtaminen: (555) dr-xr-xr-x / home / ftpuser /

teki käyttäjän kotihakemistosta EI käyttäjän kirjoitettavissa, joten minun ei tarvinnut käyttää allow_writeable_chroot = KYLLÄ. Tämä on hieno (ja turvallisempi) tilanteelleni, koska minulla on ennalta määrätty hakemistorakenne ja en halua käyttäjän tekevän uusia tiedostoja tai hakemistoja juurikansioon joka tapauksessa.

Huomasin tämän, kun vaihdoin kotihakemistoksi / var / ftp vsftpd: n local_root = -parametrin kautta ja se toimi ilman, että joudutaan asettamaan allow_writeable_chroot = KYLLÄ. Tämä kansio / var / ftp on (755), mutta juuren omistama, joten ftpuser ei voi kirjoittaa sitä.