VSFTPD FileZilla GnuTLS błąd -15 (odebrano nieoczekiwany pakiet TLS)

Po poleceniu PASS w CENTOS 7 wystąpił ten sam błąd (błąd GnuTLS -15: odebrano nieoczekiwany pakiet TLS).

Moje rozwiązanie jest następujące:

Musiałem dodać następujący tekst do vsftpd.conf:

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

Komentarze

• Dziękuję, za mój plik /etc/vsftpd.conf dodaję: user_sub_token = $ USER i teraz nie mam błędu GNUTLS -15 W tej chwili pojawia się kolejny błąd: Nie można nawiązać połączenia danych: ECONNREFUSED – Połączenie odrzucone przez serwer
• rozwiązałem na moim pliku /etc/vsftpd.conf, wstawiłem tę samą wartość dla ” listen_address = 192.168.1.2 ” & ” pasv_address = 192.168.1.2 ” dodałem to ostatnie i potrzebuję tego: D
• W moim przypadku ja miał local_root wskazujący na brakujący katalog – kiedy zmodyfikowałem tę zmienną, błąd 15 zniknął.

Publikuję tę odpowiedź w nadziei, że może to pomóc komuś w przyszłości, prawdopodobnie mnie, ponieważ cierpiałem podczas rozwiązywania tego problemu.

Nie miałem local_root w plik /etc/vsftpd/vsftpd.conf został ustawiony prawidłowo. Ustawienie wskazywało na folder, który nie istniał.

Przeze mnie zobaczyłem błąd polecenia hasła w FileZilla, więc pomyślałem, że nie podobało mu się hasło. Pomyślałem we właściwym kierunku, że poświęciłem czas na zbadanie, dlaczego nie otrzymuję szczegółowych dzienników. Nie otrzymałem żadnych logów. Kiedy zacząłem otrzymywać dzienniki debugowania, w których zobaczyłem protokoły FTP, zobaczyłem, że serwer FTP powiedział OK do hasła. Niestety nie było żadnego logowania, ale natknąłem się na myśl, że po uwierzytelnieniu hasła następnym krokiem będzie wynegocjowanie lokalnego roota. Miałem rację i to doprowadziło mnie do problemu.

Oto fragment kodu w pliku /etc/vsftpd/vsftpd.conf, zawierający lokalny katalog główny.

# 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 

Oto, jak w końcu włączyłem szczegółowe rejestrowanie, chociaż wyłączę je teraz, aby zaoszczędzić miejsce na dysku i poprawić wydajność.

# 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, uznałbym ten komentarz za błąd, ponieważ xferlog_enable to coś więcej niż faktyczne przesyłanie i pobieranie plików. Ta właściwość również włącza logowanie. Badania Google dowodzą, że log_ftp_protocol=YES wymaga xferlog_enable=YES.

Komentarze

• Właśnie wpadłem w tę samą pułapkę z powodu błędu ortograficznego. Ustawienie prawidłowego katalogu local_root rozwiązało problem.

Napotkałem dokładnie ten sam błąd (błąd: błąd GnuTLS -15: Otrzymano nieoczekiwany pakiet TLS.) I waliłem głową przez jakąś godzinę, ale potem zorientowałem się, że katalog domowy użytkowników ftp, który był na wolumenie Gluster, nie został zamontowany. Tom Mounted Gluster i problem rozwiązany.

Musisz zezwolić na zapisywalny chroot w swoim pliku konfiguracyjnym:

sudo nano /etc/vsftpd.conf 

Następnie dodaj tę linię na dole:

allow_writeable_chroot=YES 

I zrestartuj usługę:

sudo service vsftpd restart 

Co dziwne, ten problem pojawił się podczas próby ls po zalogowaniu.

Okazało się, że odinstalowałem httpd na rzecz nginx i folder, którego używałem, był własnością apache:apache, a użytkownik został usunięty, gdy usunąłem httpd. chcon „d katalogi do nginx:nginx, a następnie zastąpiłem użytkownika w tych wierszach w moim pliku konfiguracyjnym: guest_username=nginx nopriv_user=nginx

Mam nadzieję, że to komuś pomoże, ponieważ komunikaty o błędach wcale nie były pomocne.

Chciałbym dodać do Ndianabasi:

Gdy masz:

allow_writeable_chroot=NO 

i masz włączony chroot, użytkownik nie może zapisywać do katalogu Chroot użytkownika, jako którego próbujesz się zalogować. To był mój przypadek i pojawił się ten sam błąd. Podbiłem go (root dir) do root: root i to naprawiło to za mnie.

P.S. Zaznaczam, że nie mogę już znaleźć wspomnianej opcji na stronach podręcznika, ale może ona być dostępna w starszych wersjach.

Komentarze

• Jeśli odpowiedź jest to, że musisz zezwolić na zapisywalny chroot, w jaki sposób to pomoże każdemu, kto ma ten problem?

sprawdź, czy katalog i jego katalogi nadrzędne są czytelne i wykonywalne dla użytkownika sftp.

Komentarze

• Należy pamiętać, że konkretne pytanie ma zaakceptowaną odpowiedź , co oznacza, że ich problem został już rozwiązany.
• Dziękuję, ale chciałem tylko dodać, jak rozwiązałem ten problem w moim przypadku. czy uważasz, że dodanie czegoś nadal jest niewłaściwe?
• Wspomniałem o istniejącej odpowiedzi, ponieważ brzmiało to tak, jakby ten konkretny problem miał bardzo konkretną odpowiedź. Czy napotkałeś dokładnie te same objawy? Jeśli nie, zawsze możesz zapytać & o odpowiedź na swój konkretny problem swoją konkretną odpowiedzią.
• Tak, wystąpiły dokładnie te same objawy.

Nie mogę jeszcze dodawać komentarzy, więc jest to częściowo odpowiedź na komentarz Scotta i wyjaśnienie odpowiedzi Pana Fantastycznego …

Napotkałem ten sam problem i później metoda prób i błędów zorientowała się co to właściwie oznacza i lepsze rozwiązanie (IMHO) niż ustawienie allow_writeable_chroot = TAK.

Oznacza to, że vsftpd powinno pozwolić na sytuację, w której katalog domowy użytkownika jest zapisywalny przez tego użytkownika . Zamiast tego ze względów bezpieczeństwa zmieniłem uprawnienia w głównym folderze użytkownika na 555. Według innego wątku ogranicza to „ROARING BEAST ATTACK”.

W moim przypadku oryginalna konfiguracja była następująca: (777) drwxrwxrwx / home / ftpuser /

Zmiana katalogu użytkownika na: (555) dr-xr-xr-x / home / ftpuser /

uczyniło katalog domowy użytkownika NIE zapisywalne przez użytkownika i dlatego nie musiałem używać allow_writeable_chroot = YES. Jest to w porządku (i bezpieczniejsze) w mojej sytuacji, ponieważ mam wstępnie ustawioną strukturę katalogów i nie chcę, aby użytkownik i tak tworzył nowe pliki lub katalogi w swoim folderze głównym.

Rozgryzłem to po przełączeniu katalog domowy do / var / ftp za pośrednictwem parametru local_root = dla vsftpd i działał bez konieczności ustawiania allow_writeable_chroot = YES. Ten folder / var / ftp (755) jest własnością roota i dlatego ftpuser nie może go zapisywać.