Ich habe zwei neue CentOS 7-Boxen gleichzeitig eingerichtet, daher sollten die Konfigurationen identisch sein, nur unterschiedlich IP-Adressen und Hostnamen.
Ich habe VSFTPD installiert und für passive Ports konfiguriert. Eine Box verbindet sich gut, keine Probleme, aber die zweite Box löst ständig diesen Fehler aus:
GnuTLS error -15: An unexpected TLS packet was received. Hier ist der FileZilla-Debug-Trace:
Status: Connecting to 192.168.20.68:21... Status: Connection established, waiting for welcome message... Trace: CFtpControlSocket::OnReceive() Response: 220 (vsFTPd 3.0.2) Trace: CFtpControlSocket::SendNextCommand() Command: AUTH TLS Trace: CFtpControlSocket::OnReceive() Response: 234 Proceed with negotiation. Status: Initializing TLS... Trace: CTlsSocket::Handshake() Trace: CTlsSocket::ContinueHandshake() Trace: CTlsSocket::OnSend() Trace: CTlsSocket::OnRead() Trace: CTlsSocket::ContinueHandshake() Trace: CTlsSocket::OnRead() Trace: CTlsSocket::ContinueHandshake() Trace: CTlsSocket::OnRead() Trace: CTlsSocket::ContinueHandshake() Trace: TLS Handshake successful Trace: Protocol: TLS1.2, Key exchange: ECDHE-RSA, Cipher: AES-256-GCM, MAC: AEAD Status: Verifying certificate... Status: TLS connection established. Trace: CFtpControlSocket::SendNextCommand() Command: USER datamover Trace: CTlsSocket::OnRead() Trace: CFtpControlSocket::OnReceive() Response: 331 Please specify the password. Trace: CFtpControlSocket::SendNextCommand() Command: PASS ******* Trace: CTlsSocket::OnRead() Trace: CTlsSocket::Failure(-15) Error: GnuTLS error -15: An unexpected TLS packet was received. Trace: CRealControlSocket::OnClose(106) Trace: CControlSocket::DoClose(64) Trace: CFtpControlSocket::ResetOperation(66) Trace: CControlSocket::ResetOperation(66) Error: Could not connect to server Der Fehler tritt immer direkt nach der Kennwortprüfung auf.
Ich weiß, dass das Problem NICHT SELinux ist, da ich das deaktiviert habe. Das Problem ist auch nicht die Firewall, da ich versucht habe, den Firewall-Daemon (Firewalld) zu deaktivieren.
Hier ist der relevante Teil der Datei /etc/vsftpd/vsftpd.conf.
listen=YES listen_ipv6=NO pasv_enable=YES pasv_max_port=10100 pasv_min_port=10090 pasv_address=192.168.20.88 ssl_enable=YES allow_anon_ssl=NO force_local_data_ssl=YES force_local_logins_ssl=YES ssl_tlsv1=YES ssl_sslv2=NO ssl_sslv3=NO ssl_ciphers=HIGH require_ssl_reuse=NO rsa_cert_file=/etc/ssl/private/vsftpd.pem rsa_private_key_file=/etc/ssl/private/vsftpd.pem Ich habe eine Google-Suche durchgeführt, aber keine 15 Fehlercodes gesehen.
Gedanken?
Antwort
Ich hatte den gleichen Fehler nach dem PASS-Befehl in CENTOS 7. (GnuTLS-Fehler -15: Ein unerwartetes TLS-Paket wurde empfangen.)
Meine Lösung lautet wie folgt:
Ich musste folgendes zu vsftpd.conf hinzufügen:
allow_writeable_chroot=YES chroot_local_user=YES local_root=/ftphome/$USER user_sub_token=$USER Kommentare
- Vielen Dank, für meine Datei /etc/vsftpd.conf füge ich hinzu: user_sub_token = $ USER und habe jetzt nicht den GNUTLS-Fehler -15 Im Moment erhalte ich einen weiteren Fehler: Die Datenverbindung konnte nicht hergestellt werden: ECONNREFUSED – Verbindung vom Server abgelehnt
- Ich habe in meiner Datei /etc/vsftpd.conf gelöst, ich habe den gleichen Wert für “ listen_address = 192.168.1.2 “ & “ pasv_address = 192.168.1.2 “ Ich füge dies zuletzt hinzu und arbeite, ich brauche es: D
- In meinem Fall I. local_root zeigte auf ein fehlendes Verzeichnis – als ich diese Variable änderte, war Fehler 15 verschwunden.
Antwort
Ich poste diese Antwort in der Hoffnung, dass sie in Zukunft jemandem helfen könnte, möglicherweise mir, als ich unter der Lösung dieses Problems litt.
Ich hatte local_root nicht Die Datei /etc/vsftpd/vsftpd.conf wurde ordnungsgemäß festgelegt. Die Einstellung zeigte auf einen Ordner, der nicht vorhanden war.
Durch mich habe ich den Fehler beim Befehl password in FileZilla gesehen, sodass ich dachte, dass ihm das Kennwort nicht gefällt. Was mich dazu brachte, in die richtige Richtung zu denken, war, dass ich mir die Zeit genommen hatte, um zu untersuchen, warum ich keine detaillierten Protokolle erhielt. Ich habe keine Protokolle erhalten. Als ich anfing, Debug-Protokolle zu erhalten, in denen ich die FTP-Protokolle sah, sah ich, dass der FTP-Server dem Passwort OK sagte. Leider gab es keinerlei Protokollierung, aber ich kam auf den Gedanken, dass das Aushandeln des lokalen Stamms die nächste Vorgehensweise nach der Authentifizierung des Kennworts sein würde. Ich hatte Recht und das führte mich zu dem Problem.
Hier ist das Codefragment in der Datei /etc/vsftpd/vsftpd.conf, das den lokalen Stamm enthält.
# 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 So habe ich die ausführliche Protokollierung endlich aktiviert, obwohl ich sie jetzt deaktivieren werde, um Speicherplatz zu sparen und die Leistung zu verbessern.
# 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 würde ich den Kommentar als Fehler betrachten, da xferlog_enable mehr ist als das eigentliche Hoch- und Herunterladen von Dateien. Diese Eigenschaft aktiviert auch die Protokollierung. Eine Google-Studie belegt, dass log_ftp_protocol=YES xferlog_enable=YES erfordert.
Kommentare
- Ich bin gerade wegen einer Rechtschreibfehler in dieselbe Falle geraten. Das Festlegen eines gültigen local_root-Verzeichnisses hat das Problem behoben.
Antwort
Ich habe genau denselben Fehler festgestellt (Fehler: GnuTLS-Fehler) -15: Ein unerwartetes TLS-Paket wurde empfangen.) Und schlug mir eine Stunde lang den Kopf, aber dann stellte ich fest, dass das Home-Verzeichnis der FTP-Benutzer, das sich auf dem Gluster-Volume befand, nicht gemountet war. Mounted Gluster Volume und Problem behoben.
Antwort
Sie müssen eine beschreibbare Chroot in Ihrer Konfigurationsdatei zulassen:
sudo nano /etc/vsftpd.conf Fügen Sie dann diese Zeile unten hinzu:
allow_writeable_chroot=YES Starten Sie den Dienst neu:
sudo service vsftpd restart Antwort
Seltsamerweise ist dieses Problem bei dem Versuch aufgetreten, ls nach dem Anmelden.
Es stellte sich heraus, dass ich httpd zugunsten von nginx und dem deinstalliert hatte Der von mir verwendete Ordner gehörte apache:apache und der Benutzer wurde entfernt, als ich httpd entfernte. Ich chcon „d die Verzeichnisse zu nginx:nginx und ersetzte dann den Benutzer in diesen Zeilen in meiner Konfigurationsdatei: guest_username=nginx nopriv_user=nginx
Hoffentlich hilft dies jemandem da draußen, da die Fehlermeldungen überhaupt nicht hilfreich waren.
Antwort
Ich möchte Ndianabasi hinzufügen:
Wenn Sie:
haben
allow_writeable_chroot=NO und Sie haben chroot aktiviert. Das Chroot-Verzeichnis kann nicht von dem Benutzer geschrieben werden, unter dem Sie sich anmelden möchten. Dies war mein Fall und der gleiche Fehler trat auf. Ich habe es (das Root-Verzeichnis) an root: root übergeben und das hat es für mich behoben.
P.S. Ich habe überprüft, dass die erwähnte Option in den Manpages nicht mehr gefunden werden kann, sie ist jedoch möglicherweise in älteren Versionen verfügbar.
Kommentare
- Wenn die Antwort ist, dass Sie beschreibbare Chroot zulassen müssen, wie hilft dies jedem, der dieses Problem hat?
Antwort
Überprüfen Sie, ob das Verzeichnis und seine übergeordneten Verzeichnisse für den SFTP-Benutzer lesbar und ausführbar sind.
Kommentare
- Bitte beachten Sie, dass dies der Fall ist Eine bestimmte Frage hat eine akzeptierte Antwort , was bedeutet, dass ihr Problem bereits gelöst wurde.
- danke, aber ich wollte nur hinzufügen, wie ich dieses Problem gelöst habe in meinem Fall. Oder halten Sie es immer noch für unangemessen, etwas hinzuzufügen?
- Ich habe die vorhandene Antwort erwähnt, weil es so klang, als hätte dieses spezielle Problem eine sehr spezifische Antwort. Sind Sie auf genau dieselben Symptome gestoßen? Wenn nicht, Sie könnten immer fragen, & Ihr eigenes spezifisches Problem zu beantworten mit Ihrer spezifischen Antwort.
- Ja, es hatte genau die gleichen Symptome.
Antwort
Ich kann noch keine Kommentare posten, daher ist dies teilweise eine Antwort auf Scotts Kommentar und zur Klärung der Antwort von Mr.Fantastic …
Ich bin auf dasselbe Problem gestoßen und danach Einige Versuche haben herausgefunden, was dies tatsächlich bedeutet, und eine bessere Lösung (IMHO) als das Setzen von allow_writeable_chroot = YES.
Dies bedeutet, dass vsftpd die Situation zulassen sollte, in der das Home-Verzeichnis des Benutzers von diesem Benutzer beschreibbar ist . Stattdessen habe ich aus Sicherheitsgründen die Berechtigungen für den Stammordner des Benutzers in 555 geändert. Laut einem anderen Thread wird dadurch ein „ROARING BEAST ATTACK“ gemindert.
In meinem Fall war das ursprüngliche Setup: (777) drwxrwxrwx / home / ftpuser /
Durch Ändern des Benutzerverzeichnisses in: (555) dr-xr-xr-x / home / ftpuser /
wurde das Basisverzeichnis des Benutzers NICHT festgelegt Vom Benutzer beschreibbar und daher musste ich nicht allow_writeable_chroot = YES verwenden. Dies ist in Ordnung (und sicherer) für meine Situation, da ich eine voreingestellte Verzeichnisstruktur habe und nicht möchte, dass der Benutzer sowieso neue Dateien oder Verzeichnisse in seinem Stammordner erstellt.
Ich habe dies beim Wechsel herausgefunden Das Home-Verzeichnis nach / var / ftp über den Parameter local_root = für vsftpd und es funktionierte, ohne allow_writeable_chroot = YES setzen zu müssen. Dieser Ordner / var / ftp ist (755), gehört jedoch root und kann daher nicht von ftpuser geschrieben werden >