[Problem] Zugriff auf FTP-Server führt zu Reboot

vsftp möchte ich eigentlich umgehen. Mit ihren 8MB ist die 7170 ja nicht gerade üppig mit Speicher gesegnet und ich möchte nicht unbedingt auf externe Pakete ausweichen.
 
@Di3a: Bei einer 7170 bleibt leider kaum Alternative übrig, als auf External auszuweichen. Momentan habe ich zwar keine 7170 produktiv im Einsatz, hatte aber bis vor kurzem. Meine Erfahrungen mit einem externalisierten vsftp waren recht gut, sodass ich dir vsftp als Ersatz für AVM-FTP wirklich empfehlen würde. Beim AVM-FTP hatten wir vor langer Zeit vor gehabt den zu verstehen und für uns besser zu adaptieren. Oliver hatte ihn sich damals vorgenommen und leider festgestellt, dass AVM diesen eigentlich recht guten FTPD ziemlich stark "kastriert" haben und dem seine eigentlich recht gute Benutzerverwaltung somit "wegoptimiert" hatten. Diese Klimmzüge mit "ftpuser" und "boxuser80" (oder wie sie auch immer bei AVM alle heißen) ist echt eine Katastrophe. Das was FREETZ mit dem AVM-FTP macht, bewegt sich eher in der Workarround-Nische, um eine halbwegs vernünftige Umgebung für den besagten Server zu basteln und dennoch dies auch mit der Benutzerverwaltung halbwegs zu "verheiraten". Bei VSFTP läuft alles dagegen nativ und greift nicht auf die eingebauten SSL-Mechanismen von AVM. Und diese Mechanismen (und vor allem Veränderungen seitens AVM) kennen wir leider nicht so gut, weil SSL eine spezielle Lizenz besitzt.

MfG
 
Ich habe jetzt vsftp eingebaut und bin dabei gleich auf freetz-trunk umgestiegen.
Ich hatte die Hoffnung, dass evtl im trunk der AVM ftpd funktioniert, aber der verursacht dort auch wieder einen reboot.
Ich habe jetzt versucht, vsftp zu konfigurieren bekomme aber keine Verbindung hin.
Wenn ich in Filezilla sftp versuche, gibts einfach einen Timeout. Mit ftpes kommt eine Verbindung zustande, die dann aber mit GnuTLS push Error -53 abbricht.
Meine Einstellungen:
Starttyp: Manuell (ist aber gestartet)
Port: 44690
Zugriff (aktivierte Optionen): Lokale Benutzer, chrootjail, Erlaube ftpuser login
SSL-Einstellungen: alle Optionen aktiviert
Erweiterte Einstellungen (unverändert): # Verbindungen 25/5, aktuelle öffentliche IP als pasv_address eintragen, Script /etc/onlinechanged/reload_vsftpd aktivieren
Was mache ich falsch?
Kennt außerdem jemand eine speziell auf freetz zugeshcnittene Konfigurationsanleitung für vsftp? Ich habe bis jetzt immer nur Fragmente gefunden bzw. vfstp Konfiguration für Debian.
 
Wenn ich in Filezilla sftp versuche, gibts einfach einen Timeout.
Das ist richtig, den sftp ist kein ftp. Für sftp brauchst Du einen ssh-Server und keinen ftp-Server.
Was mache ich falsch?
Du benutzt nicht den richtigen FTP-Client für ftps bzw. ftpes. Versuch es mal mit einer Filezilla-Version die z. B., gegen GnuTLS 2.8.6 gelinkt ist.
 
Das ist ja echt mal wieder peinlich, dass die aktuelle GnuTLS-Veriante solche Macken hat.
Ich habe es jetzt mal mit FileZilla 3.1.1.1 versucht. Damit kommt der Login in vsftp zustande.
Es scheitert dann aber wieder mal am List-Kommando. Zwar bootet die Box nicht neu, Filezilla meldet aber:
Befehl: LIST
Fehler: Zeitüberschreitung der Verbindung
Fehler: Verzeichnisinhalt konnte nicht empfangen werden
Das Log von vsftp auf der Fritzbox sagt:
CONNECT: Client "IP"
OK LOGIN: Client "IP"
CONNECT: "Client "IP"
OK LOGIN Client
DEBUG: Client "IP", "Connection terminated without SSL shutdown - buggy client?"

Zur Konfiguration habe ich mich an http://freetz.org/wiki/packages/vsftpd gehalten. Zur Zeit gibts nur nen User user1.
Was mache ich jetzt noch falsch?
 
Wenn das Login funktioniert, aber das darauf folgende LIST (oder eine Datenübertragung) nicht, liegt es meistens daran, dass keine Datenverbindung aufgebaut werden kann.
Verwendest Du aktives oder passives FTP? In der verlinkten Beschreibung selbst steht auch nichts davon, dass man dafür sorgen muss, dass die Datenverbindung von Außen funktioniert, aber unten ist noch ein Link auf [THREAD=176105]Aktives/passives FTP auf die Box von Außen mit vsftpd auf der Box[/THREAD]. Hast Du den auch gelesen?
 
Eine richtige Lösung sehe ich in dem zusätzlichen Beitrag nicht.
Intern gelange ich mit aktivem FTP auf doe Box, extenr nicht. Nur schweigt sich der o.g. Beitrag darüber aus, wie denn die Portweiterleitung aussehen muss. Muss ich Port 20 auf die Box forwarden? Und wie sieht das genau für FTPES aus?
 
Intern läuft die Kommunikation ebenfalls über ftpes.
Und die Firewall des Clients lässt die Verbindung zu.
Ich habe übrigens noch die Einstellungen etwas modifiziert:

user_config_dir=/var/media/ftp/uStor01/vsftp_user_conf
port_enable=yes
require_ssl_reuse=no
pasv_enable=no

Außerdem funktioniert jetzt intern auch der passive Modus.
Greife ich über die externe IP zu, gibts je nach Verbindungs-Typ unterschiedliche Fehlermeldungen:
passiv :
Befehl: PASV
Antwort: 550 Permission denied.
Befehl: PORT 192,168,3,9,167,4
Antwort: 500 Illegal PORT command.
Fehler: Verzeichnisinhalt konnte nicht empfangen werden
aktiv:
Befehl: PORT 192,168,3,9,179,77
Antwort: 500 Illegal PORT command.
Befehl: PASV
Antwort: 550 Permission denied.
Fehler: Verzeichnisinhalt konnte nicht empfangen werden

soviel zum aktuellen Stand.
 
Greife ich über die externe IP zu, gibts je ...
Greifts Du von deinem _eigenen_ Internetanschluss oder von einem fremden Internetanschluss auf deine externe (öffentliche) IP-Adresse zu?
 
Zum Testen meistens vom eigenen Anschluss aus, um dadurch Einflüsse auszuschließen aber auch von einem externen Rechner.
 
Einflüsse dadurch, dass ich selber auf meine externe IP-Adresse zugreife. Deshalb versuche ich es auch von einem externen Rechner aus, X-Forwarding und ssh sind da sehr praktisch...
 
Außerdem funktioniert jetzt intern auch der passive Modus.
Greife ich über die externe IP zu, gibts je nach Verbindungs-Typ unterschiedliche Fehlermeldungen:
Die Meldungen sehen sehr ähnlich aus, nur die Reihenfolge ist vertauscht. Und in beiden Fällen wird das Kommando PASV (passiv) gesendet und mit "550 Permission denied" beantwortet.

Anscheinend versucht der Client im oberen Fall erst passiv dann aktiv, beides geht nicht.
Im unteren Fall versucht der Client zuerst aktiv dann passiv, auch hier geht beides nicht.
 
Einflüsse dadurch, ...
Meine Frage war nicht _weshalb_ Einflüsse, sondern _welche_ Einflüsse Du meinst. _BTW_: Deine Beiträge #33 und #35 sind kontradiktorisch/widersprüchlich.
 
Meine Frage war nicht _weshalb_ Einflüsse, sondern _welche_ Einflüsse Du meinst. _BTW_: Deine Beiträge #33 und #35 sind kontradiktorisch/widersprüchlich.
Ich beziehe mich dabei auf Deinen eigenen Beitrag (#7 in diesem Thread). Un meine beiden Beiträge widersprechen sich durchaus nicht. Ich habe geschrieben, dass ich beides versuche, als "Schnelltest" aber meistens (nicht immer !) von meinem eigenen Rechner aus den Versuch starte.

Das oben beschriebene Verhalten lässt sich aber wie gesagt auch von externen Rechnern aus reproduzieren.
 
Anscheinend versucht der Client im oberen Fall erst passiv dann aktiv, beides geht nicht.
Im unteren Fall versucht der Client zuerst aktiv dann passiv, auch hier geht beides nicht.
Ja, das ist mir auch aufgefallen. Aber was genau geht da schief?
Muss ich evtl. den TCP-Port 20 noch manuell freigeben?
 
Aber was genau geht da schief?
Wenn ich im LAN oder auch über das Internet (d. h. fremder Internetanschluss, nicht vom eigenen), mit Filezilla auf den vsftpd _passiv_ zugreife, dann brauche ich für den vsftpd _unterschiedliche_ Konfigurationen, abhängig ob der Zugriff per ftp oder per ftps erfolgt. Als Beispiel, hier die anonymisierte Konfiguration des vsftpd für passiven Zugriff im LAN per ftps (mit Filezilla):
listen=YES
ftpd_banner=<blah blah blah!>
local_enable=YES
userlist_deny=NO
userlist_enable=YES
userlist_file=</Pfad/vsftpd.user_list>
nopriv_user=<user_x>
write_enable=YES
download_enable=YES
listen_port=<port1>
pasv_min_port=<port_min>
pasv_max_port=<port_max>
hide_file={.*}
deny_file={*.exe,*.com,*.dll}
hide_ids=YES
chroot_local_user=YES
ssl_enable=YES
ssl_request_cert=YES
strict_ssl_read_eof=YES
strict_ssl_write_shutdown=YES
implicit_ssl=YES
allow_anon_ssl=NO
force_local_data_ssl=NO
force_local_logins_ssl=NO
ssl_tlsv1=YES
ssl_sslv2=YES
ssl_sslv3=YES
ssl_ciphers=HIGH
rsa_cert_file=</Pfad/xxx.pem>
secure_chroot_dir=</Pfad/empty>
syslog_enable=NO
max_clients=3
max_per_ip=3
delay_failed_login=15
delay_successful_login=15
max_login_fails=2
anonymous_enable=NO
use_localtime=YES
connect_timeout=30
data_connection_timeout=600
idle_session_timeout=120
file_open_mode=0644
guest_enable=NO
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.