Hallo zusammen! Sagt mal, gibt es irgendwelche Schwierigkeiten oder Besonderheiten beim Betrieb des vsftpd mit SUSE10.1??? Ich werde hier langsam verrückt! Hab alles so installiert wie früher (SUSE 9.1) auch: make make install altes vsftp.conf auf den neuen Server kopiert (nach /etc/) Ich hab die Versionen 2.0.3 und 2.0.5 getestet. Problem: Der vsftpd läuft scheinbar - logs funktionieren - aber ich kann keinen User einloggen! Im Log steht: [username] FAIL LOGIN: User sind als localeusers aktiviert und der Server läuft im Standalonemode. Mit dem user "username" kann ich mich per ssh so einloggen - das klappt. Aber nicht per FTP! Hat jemand ne Idee, was das sein könnte??? Das wäre große Klasse!! Viele Grüße Fritz
Fritz Mundtart wrote:
Hallo zusammen!
Sagt mal, gibt es irgendwelche Schwierigkeiten oder Besonderheiten beim Betrieb des vsftpd mit SUSE10.1??? Ich werde hier langsam verrückt! Hab alles so installiert wie früher (SUSE 9.1) auch:
make make install
altes vsftp.conf auf den neuen Server kopiert (nach /etc/)
Da würde ich vorsichtig mit sein. Wenn sich Defaults geändert haben zwischen den Versionen, kann es Überraschungen geben.
Ich hab die Versionen 2.0.3 und 2.0.5 getestet.
Problem: Der vsftpd läuft scheinbar - logs funktionieren - aber ich kann keinen User einloggen! Im Log steht: [username] FAIL LOGIN:
User sind als localeusers aktiviert und der Server läuft im Standalonemode. Mit dem user "username" kann ich mich per ssh so einloggen - das klappt. Aber nicht per FTP!
Hat jemand ne Idee, was das sein könnte??? Das wäre große Klasse!!
Was ist denn unerwünscht bei der von Suse mitgelieferten Version? Die sollte eine funktionierende Konfig direkt mitbringen. Ohne Konfigdaten ist das ein ziemliches Raten. Versuche es doch mal auf ungekehrte Art: Wenn du schon eine Neuinstallation machst ohne Übernahme der alten Daten, dann installiere doch mal das RPM von Suse, teste den Login und füge dann die abweichenden Konfigurationsparameter hinzu. Dann kannst du ja vergleichen, wo, wenn überhaupt, die Konfiguration bricht. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Hallo Sandy! Hallo Liste! Sandy Drobic schrieb:
Fritz Mundtart wrote:
[...] altes vsftp.conf auf den neuen Server kopiert (nach /etc/)
Da würde ich vorsichtig mit sein. Wenn sich Defaults geändert haben zwischen den Versionen, kann es Überraschungen geben. Ja, da hast Du Recht! Aber es waren so fast die gleichen Versionen: Alter Server 2.0.3 und auf dem neuen nach der 2.0.5 ebenfalls die 2.0.3. Das müsste dann ja klappen.
[...] Was ist denn unerwünscht bei der von Suse mitgelieferten Version? Die sollte eine funktionierende Konfig direkt mitbringen. Hmm ... ja. Ich weiß nicht. Irgendein Instinkt sagt mir, daß ich es von Hand installieren sollte. Hab das Gefühl, dann besser den Überblick zu behalten. Liegt vermutlich am Apachen. Den installiere ich seit Jahren von Hand. In den Pfaden, die Yast einbaut, finde ich mich bisher nicht so zurecht. Ich habe mich aber auch noch nie länger als 5 Minuten damit auseinander gesetzt ;-) Ist also wohl eher die Macht der Gewohnheit ;-)
Ohne Konfigdaten ist das ein ziemliches Raten. Versuche es doch mal auf ungekehrte Art: Wenn du schon eine Neuinstallation machst ohne Übernahme der alten Daten, dann installiere doch mal das RPM von Suse, teste den Login und füge dann die abweichenden Konfigurationsparameter hinzu. Gute Idee! Hat auch schon geklappt!
Lösung: Wenn KEIN SSL vorhanden ist, so ist SSL explizit abzuschalten - also den Schalter auf NO zusetzen. (Muß mir mal FTP mit SSL ansehen. Das klingt gut ;-) ) Vielen Dank und viele Grüße Fritz
Hallo Sandy! Hallo Liste! Fritz Mundtart schrieb:
[...]
Lösung: Wenn KEIN SSL vorhanden ist, so ist SSL explizit abzuschalten - also den Schalter auf NO zu setzen. [...] Ähm, für den Anfang ging das ganz gut. Aber jetzt gibt es ein neues Problem:
Von Windows aus kann ich mich wunderbar mittels Console, TotalCommander (bzw. WinCommander) oder GoLive verbinden und Daten transferieren, aber vom MAC und von Linux aus hakt es! Ich kann mich unter Linux verbinden und einloggen. Soweit so gut. Sende ich nun ein "ls" ab, dann gibt es ein "Entering Extended Passive Mode" und das System hängt. Nach etlichen Augenblicken (Minuten) wird erst das Directory geliefert. Woran könnte das nun wieder liegen??? Viele Grüße Fritz
Fritz Mundtart, Mittwoch, 1. November 2006 13:04:
Von Windows aus kann ich mich wunderbar mittels Console, TotalCommander (bzw. WinCommander) oder GoLive verbinden und Daten transferieren, aber vom MAC und von Linux aus hakt es!
Ich kann mich unter Linux verbinden und einloggen. Soweit so gut. Sende ich nun ein "ls" ab, dann gibt es ein "Entering Extended Passive Mode" und das System hängt. Nach etlichen Augenblicken (Minuten) wird erst das Directory geliefert.
Mehrere Ideen: - Hast Du .local als Domäne eingerichtet? Die werden nämlich unter Windows normal, unter Mac und Linux aber per Multicast aufgelöst. Lösung: .local in .wasweisichwas ändern. Dann läufst Du nicht mehr dauernd in einen Timeout. - Unter Linux ist der lukemftp standardmäßig im ASCII-Mode, und hat epsv/eprt aktiviert. Daher muß man da immer ein binary epsv verfüttern, bevor Übertragungen klappen. - Generelle DNS-Probleme mit entsprechenden Timeouts? - -- Andre Tann
Hallo Andre, Andre Tann schrieb:
[...] Mehrere Ideen:
- Hast Du .local als Domäne eingerichtet? Die werden nämlich unter Windows normal, unter Mac und Linux aber per Multicast aufgelöst. Lösung: .local in .wasweisichwas ändern. Dann läufst Du nicht mehr dauernd in einen Timeout.
Wenn man im Text-Mode dicke, fette, große Fragezeichen und ein verwirrtes Gesicht malen könnte, dann würde ich es hier und jetzt malen ;-)) Was ist .local??? Hat das was mit dem guten localhost zu tun? Geht es um das .local auf dem FTP-Server oder dem FTP-Client? Wo stellt man das und wie ein?
- Unter Linux ist der lukemftp standardmäßig im ASCII-Mode, und hat epsv/eprt aktiviert. Daher muß man da immer ein
binary epsv
verfüttern, bevor Übertragungen klappen.
Aha .... Ohne binary und epsv gibt es auch einen "500 Illegal EPRT command" Error bevor das Directory gesendet wird. Schick ich dem FTP Server ein binary und epsv, dauert es immer noch Jahre bis zur Ausgabe, aber es kommt kein EPRT Fehler mehr. Der "Extended Passive Mode" weicht dann auch einem reinen "Passive Mode" ...
- Generelle DNS-Probleme mit entsprechenden Timeouts?
Hmm .... eigentlich nicht. Gehe auch über die IP direkt rein ... Viele Grüße Fritz
Fritz Mundtart, Mittwoch, 1. November 2006 14:33:
Wenn man im Text-Mode dicke, fette, große Fragezeichen und ein verwirrtes Gesicht malen könnte, dann würde ich es hier und jetzt malen ;-)) Was ist .local??? Hat das was mit dem guten localhost zu tun? Geht es um das .local auf dem FTP-Server oder dem FTP-Client? Wo stellt man das und wie ein?
Hat mit all dem nichts zu tun. Wenn Du als lokale Domäne irgendwas aufsetzt, was auf .local endet, dann könntest Du damit Probleme kriegen. Aber nachdem Du nicht weißt, wovon ich spreche, hast Du es vermutlich auch nicht aufgesetzt. Also vergessen wir diesen Punkt.
- Generelle DNS-Probleme mit entsprechenden Timeouts?
Hmm .... eigentlich nicht. Gehe auch über die IP direkt rein ...
Das hat nichts zu sagen. Kann denn der Server die IP in einen Hostnamen auflösen, und umgekehrt? Das wird nämlich der vsftp versuchen und warten, ob das klappt. Wenn es nach 30 Sekunden oder so noch nicht geklappt hat, dann gehts eben ohne Auflösung weiter. Ergo: sorge dafür, daß die IP nen Namen hat, und Du vermeidest diese Timeouts. -- Andre Tann
Hallo Andre, hallo Liste! Andre Tann schrieb:
[...] Aber nachdem Du nicht weißt, wovon ich spreche, hast Du es vermutlich auch nicht aufgesetzt. Also vergessen wir diesen Punkt.
Ay ;)
- Generelle DNS-Probleme mit entsprechenden Timeouts?
Hmm .... eigentlich nicht. Gehe auch über die IP direkt rein ...
Das hat nichts zu sagen. Kann denn der Server die IP in einen Hostnamen auflösen, und umgekehrt? Ja, das geht. Allerdings ist der Hostname ein anderer als der, der mittels # host <IPADR> aufgelöst wird. Ist das entscheidend?
Das wird nämlich der vsftp versuchen und warten, ob das klappt. Versucht der vsftp sich selbst also den Server aufzulösen oder den Client?
Ich hab mal noch einen Test gemacht - vielleicht gibt der ja weitere Aufschlüsse: Ich hab mich von der FTP Server Console auf dem selben Server (quasi localhost) eingeloggt. So geht alles fix und wunderbar. Gruß Fritz
Fritz Mundtart wrote:
Hallo Andre, hallo Liste!
Andre Tann schrieb:
[...] Aber nachdem Du nicht weißt, wovon ich spreche, hast Du es vermutlich auch nicht aufgesetzt. Also vergessen wir diesen Punkt.
Ay ;)
- Generelle DNS-Probleme mit entsprechenden Timeouts?
Hmm .... eigentlich nicht. Gehe auch über die IP direkt rein ...
Das hat nichts zu sagen. Kann denn der Server die IP in einen Hostnamen auflösen, und umgekehrt? Ja, das geht. Allerdings ist der Hostname ein anderer als der, der mittels # host <IPADR> aufgelöst wird. Ist das entscheidend?
Das wird nämlich der vsftp versuchen und warten, ob das klappt. Versucht der vsftp sich selbst also den Server aufzulösen oder den Client?
Ich hab mal noch einen Test gemacht - vielleicht gibt der ja weitere Aufschlüsse: Ich hab mich von der FTP Server Console auf dem selben Server (quasi localhost) eingeloggt. So geht alles fix und wunderbar.
Das riecht in der Tat stark nach einem Time-out der DNS-Auflösung. Nimm mal die IPs deiner Clients in die /etc/hosts von deinem vsftpd Server auf. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Fritz Mundtart, Donnerstag, 2. November 2006 13:54:
Ja, das geht. Allerdings ist der Hostname ein anderer als der, der mittels # host <IPADR> aufgelöst wird. Ist das entscheidend?
Könnte schon sein, da bin ich nicht sicher. sshd jedenfalls würde darüber meckern.
Versucht der vsftp sich selbst also den Server aufzulösen oder den Client?
Der Server versucht, den zugreifenden Client zu verifizieren. Versuch doch mal quick&dirty durch einen Eintrag in die /etc/hosts eine konsistente Auflösung einzurichten. Ändert sich was?
Ich hab mich von der FTP Server Console auf dem selben Server (quasi localhost) eingeloggt. So geht alles fix und wunderbar.
Deutet auf DNS hin. -- Andre Tann
Mojn Sandy, Sandy Drobic schrieb:
Fritz Mundtart wrote:
[...]
Ich hab mal noch einen Test gemacht - vielleicht gibt der ja weitere Aufschlüsse: Ich hab mich von der FTP Server Console auf dem selben Server (quasi localhost) eingeloggt. So geht alles fix und wunderbar.
Das riecht in der Tat stark nach einem Time-out der DNS-Auflösung. Nimm mal die IPs deiner Clients in die /etc/hosts von deinem vsftpd Server auf. OK, ich probiers mal aus! Wie war 'n das: ist die hosts automatisch "aktiv" oder muß ich die irgendwie über ein "rcnetwork restart" einlesen?
... ähm ... vielleicht eine dumme Frage am Rande : ist das wirklich eine gangbare Möglichkeit für Clients, die dynamische IPs haben? Grüße Fritz
Fritz Mundtart, Freitag, 3. November 2006 08:41:
OK, ich probiers mal aus! Wie war 'n das: ist die hosts automatisch "aktiv" oder muß ich die irgendwie über ein "rcnetwork restart" einlesen?
Wird jedesmal automatisch eingelesen. Kein rcnetwork restart nötig.
... ähm ... vielleicht eine dumme Frage am Rande : ist das wirklich eine gangbare Möglichkeit für Clients, die dynamische IPs haben?
Nein, dafür brauchst Du nur eine "normale" Möglichkeit der Auflösung. Denn die meisten dynamischen Clients haben auch einen gültigen DNS-Eintrag. -- Andre Tann
Mojn Andre, Andre Tann schrieb:
Fritz Mundtart, Freitag, 3. November 2006 08:41:
[...] oder muß ich die irgendwie über ein "rcnetwork restart" einlesen?
Wird jedesmal automatisch eingelesen. Kein rcnetwork restart nötig.
OK! Ein ping auf den Hostnamen klappt. Ich hab mal spaßeshalber einen Client mit fester IP eingebunden und auch nochmal meine dynamische IP und den dazugehörigen Hostnamen vom Provider, aber das hilft bisher nicht wirklich :(
[...] Nein, dafür brauchst Du nur eine "normale" Möglichkeit der Auflösung. Sprich die Erreichbarkeit eines DNS Servers. Richtig? Also ein host <ipadresse> funktioniert und liefert den korrekten Namen zurück....
Ich hab noch was anderes herausgefunden: Wenn ich beim Einloggen vom Linux Client aus das FTP mit Aktiv-Mode starte (ftp -A <ip>) oder in der vsftpd.config den Parameter pasv_enable=NO setze, dann funktioniert das ganze ohne Zeitverzögerung! Was sagt uns das? Spricht es eher für die DNS Theorie oder für etwas ganz anderes? Viele Grüße Fritz
Fritz Mundtart wrote:
Mojn Andre,
Andre Tann schrieb:
Fritz Mundtart, Freitag, 3. November 2006 08:41:
[...] oder muß ich die irgendwie über ein "rcnetwork restart" einlesen?
Wird jedesmal automatisch eingelesen. Kein rcnetwork restart nötig.
OK! Ein ping auf den Hostnamen klappt. Ich hab mal spaßeshalber einen Client mit fester IP eingebunden und auch nochmal meine dynamische IP und den dazugehörigen Hostnamen vom Provider, aber das hilft bisher nicht wirklich :(
Wenn das externe Clients sind, deren IP man nicht selbst festlegen kann, hilft das nicht.
[...] Nein, dafür brauchst Du nur eine "normale" Möglichkeit der Auflösung. Sprich die Erreichbarkeit eines DNS Servers. Richtig? Also ein host <ipadresse> funktioniert und liefert den korrekten Namen zurück....
Ich hab noch was anderes herausgefunden: Wenn ich beim Einloggen vom Linux Client aus das FTP mit Aktiv-Mode starte (ftp -A <ip>) oder in der vsftpd.config den Parameter pasv_enable=NO setze, dann funktioniert das ganze ohne Zeitverzögerung!
Was sagt uns das? Spricht es eher für die DNS Theorie oder für etwas ganz anderes?
Eher dagegen, denn Aktiv oder Passiv hat nichts mit den Hostnamen zu tun, eher mit der Konfiguration von AppArmor und Konsorten. Gibt es irgendwelche Hinweise in /var/log/messages /var/log/auth.log oder welchem Log du vsftpd zugeordnet hast? Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Hi Sandy, Sandy Drobic schrieb:
[...]
Ich hab noch was anderes herausgefunden: Wenn ich beim Einloggen vom Linux Client aus das FTP mit Aktiv-Mode starte (ftp -A <ip>) oder in der vsftpd.config den Parameter pasv_enable=NO setze, dann funktioniert das ganze ohne Zeitverzögerung!
Was sagt uns das? Spricht es eher für die DNS Theorie oder für etwas ganz anderes?
Eher dagegen, denn Aktiv oder Passiv hat nichts mit den Hostnamen zu tun, eher mit der Konfiguration von AppArmor und Konsorten. AppArmor? Davon hab ich schon mal hi und da gelesen. Was genau (oder ungenau ;-) ) ist das eigentlich? Wenn ich mich recht entsinne, dann ist es wohl eine Neuerung bei 10.1, oder? Wer an "Konsorten" gehört da noch dazu?
Gibt es irgendwelche Hinweise in /var/log/messages /var/log/auth.log oder welchem Log du vsftpd zugeordnet hast? Hier mal die Infos einer Loginsession aus dem vsftpd.log (in messages, warn und zmd-* steht nix zu dieser Uhrzeit):
********************************* Sat Nov 4 01:52:50 2006 [pid 5921] [user] FTP response: Client "1.2.3.4", "331 Please specify the password." Sat Nov 4 01:52:56 2006 [pid 5921] [user] FTP command: Client "1.2.3.4", "PASS <password>" Sat Nov 4 02:52:56 2006 [pid 5920] [user] OK LOGIN: Client "1.2.3.4" Sat Nov 4 02:52:56 2006 [pid 5922] [user] FTP response: Client "1.2.3.4", "230 Login successful." Sat Nov 4 01:52:56 2006 [pid 5922] [user] FTP command: Client "1.2.3.4", "SYST" Sat Nov 4 01:52:56 2006 [pid 5922] [user] FTP response: Client "1.2.3.4", "215 UNIX Type: L8" Sat Nov 4 01:52:56 2006 [pid 5922] [user] FTP command: Client "1.2.3.4", "FEAT" Sat Nov 4 01:52:56 2006 [pid 5922] [user] FTP response: Client "1.2.3.4", "211-Features:" Sat Nov 4 01:52:56 2006 [pid 5922] [user] FTP response: Client "1.2.3.4", " EPRT??" Sat Nov 4 01:52:56 2006 [pid 5922] [user] FTP response: Client "1.2.3.4", " EPSV??" Sat Nov 4 01:52:56 2006 [pid 5922] [user] FTP response: Client "1.2.3.4", " MDTM??" Sat Nov 4 01:52:56 2006 [pid 5922] [user] FTP response: Client "1.2.3.4", " PASV??" Sat Nov 4 01:52:56 2006 [pid 5922] [user] FTP response: Client "1.2.3.4", " REST STREAM??" Sat Nov 4 01:52:56 2006 [pid 5922] [user] FTP response: Client "1.2.3.4", " SIZE??" Sat Nov 4 01:52:56 2006 [pid 5922] [user] FTP response: Client "1.2.3.4", " TVFS??" Sat Nov 4 01:52:56 2006 [pid 5922] [user] FTP response: Client "1.2.3.4", "211 End" Sat Nov 4 01:52:56 2006 [pid 5922] [user] FTP command: Client "1.2.3.4", "PWD" Sat Nov 4 01:52:56 2006 [pid 5922] [user] FTP response: Client "1.2.3.4", "257 "/"" Sat Nov 4 01:52:58 2006 [pid 5922] [user] FTP command: Client "1.2.3.4", "EPRT |1|192.168.0.10|49708|" Sat Nov 4 01:52:58 2006 [pid 5922] [user] FTP response: Client "1.2.3.4", "500 Illegal EPRT command." Sat Nov 4 01:52:58 2006 [pid 5922] [user] FTP command: Client "1.2.3.4", "PORT 1,2,3,4,194,44" Sat Nov 4 01:52:58 2006 [pid 5922] [user] FTP response: Client "1.2.3.4", "200 PORT command successful. Consider using PASV." Sat Nov 4 01:52:58 2006 [pid 5922] [user] FTP command: Client "1.2.3.4", "LIST" Sat Nov 4 01:53:58 2006 [pid 5922] [user] FTP response: Client "1.2.3.4", "425 Failed to establish connection." ********************************* Sagt einem von Euch das etwas Näheres? (Abgesehen davon, daß der Rechner in der Zukunft arbeitet ;-) ) Viele Grüße Fritz
Fritz Mundtart wrote:
Hi Sandy,
Sandy Drobic schrieb:
[...]
Ich hab noch was anderes herausgefunden: Wenn ich beim Einloggen vom Linux Client aus das FTP mit Aktiv-Mode starte (ftp -A <ip>) oder in der vsftpd.config den Parameter pasv_enable=NO setze, dann funktioniert das ganze ohne Zeitverzögerung!
Was sagt uns das? Spricht es eher für die DNS Theorie oder für etwas ganz anderes?
Eher dagegen, denn Aktiv oder Passiv hat nichts mit den Hostnamen zu tun, eher mit der Konfiguration von AppArmor und Konsorten. AppArmor? Davon hab ich schon mal hi und da gelesen. Was genau (oder ungenau ;-) ) ist das eigentlich? Wenn ich mich recht entsinne, dann ist es wohl eine Neuerung bei 10.1, oder? Wer an "Konsorten" gehört da noch dazu?
AppArmor ist seit 10.0 im Kernel integriert und beschränkt die Rechte eines Programms, wenn ein entsprechendes AppArmor-Profil angelegt ist. Seit 10.1 ist AppArmor als Standard aktiv, wenn der Benutzer dies nicht explizit abschaltet. Weitere "Spaßbremsen" könnten zum Beispiel die Firewall sein, oder rigide eingestellte /etc/permissions, oder eine chroot Konfiguration eines Serverdienstes.
Gibt es irgendwelche Hinweise in /var/log/messages /var/log/auth.log oder welchem Log du vsftpd zugeordnet hast? Hier mal die Infos einer Loginsession aus dem vsftpd.log (in messages, warn und zmd-* steht nix zu dieser Uhrzeit):
********************************* Sat Nov 4 01:52:50 2006 [pid 5921] [user] FTP response: Client "1.2.3.4", "331 Please specify the password." Sat Nov 4 01:52:56 2006 [pid 5921] [user] FTP command: Client "1.2.3.4", "PASS <password>" Sat Nov 4 02:52:56 2006 [pid 5920] [user] OK LOGIN: Client "1.2.3.4" Sat Nov 4 02:52:56 2006 [pid 5922] [user] FTP response: Client "1.2.3.4", "230 Login successful."
Okay, soweit in Ordnung, Client ist erfolgreich eingeloggt.
Sat Nov 4 01:52:56 2006 [pid 5922] [user] FTP command: Client "1.2.3.4", "SYST" Sat Nov 4 01:52:56 2006 [pid 5922] [user] FTP response: Client "1.2.3.4", "215 UNIX Type: L8"
Client weiss jetzt, dass es sich um ein Linux-System handelt.
Sat Nov 4 01:52:56 2006 [pid 5922] [user] FTP command: Client "1.2.3.4", "FEAT"
Client fragt, welche Möglichkeiten/Befehle der Server zur Verfügung stellt:
Sat Nov 4 01:52:56 2006 [pid 5922] [user] FTP response: Client "1.2.3.4", "211-Features:" Sat Nov 4 01:52:56 2006 [pid 5922] [user] FTP response: Client "1.2.3.4", " EPRT??" Sat Nov 4 01:52:56 2006 [pid 5922] [user] FTP response: Client "1.2.3.4", " EPSV??" Sat Nov 4 01:52:56 2006 [pid 5922] [user] FTP response: Client "1.2.3.4", " MDTM??" Sat Nov 4 01:52:56 2006 [pid 5922] [user] FTP response: Client "1.2.3.4", " PASV??" Sat Nov 4 01:52:56 2006 [pid 5922] [user] FTP response: Client "1.2.3.4", " REST STREAM??" Sat Nov 4 01:52:56 2006 [pid 5922] [user] FTP response: Client "1.2.3.4", " SIZE??" Sat Nov 4 01:52:56 2006 [pid 5922] [user] FTP response: Client "1.2.3.4", " TVFS??" Sat Nov 4 01:52:56 2006 [pid 5922] [user] FTP response: Client "1.2.3.4", "211 End"
Unter anderem also Extended Passiv und Passive Übertragung.
Sat Nov 4 01:52:56 2006 [pid 5922] [user] FTP command: Client "1.2.3.4", "PWD" Sat Nov 4 01:52:56 2006 [pid 5922] [user] FTP response: Client "1.2.3.4", "257 "/""
In welchem Verzeichnis bin ich eingeloggt...
Sat Nov 4 01:52:58 2006 [pid 5922] [user] FTP command: Client "1.2.3.4", "EPRT |1|192.168.0.10|49708|" Sat Nov 4 01:52:58 2006 [pid 5922] [user] FTP response: Client "1.2.3.4", "500 Illegal EPRT command."
Das hier ist schon interessanter. Der Client versucht mit, den Datenkanal auszuhandeln über das Extended Port Kommando EPRT. Dies schlägt fehl, obwohl ich hier keinen Grund dafür sehe, denn das Kommando sieht gültig aus.
Sat Nov 4 01:52:58 2006 [pid 5922] [user] FTP command: Client "1.2.3.4", "PORT 1,2,3,4,194,44" Sat Nov 4 01:52:58 2006 [pid 5922] [user] FTP response: Client "1.2.3.4", "200 PORT command successful. Consider using PASV."
Client fällt also zurück auf das normale PORT Kommando, welches erfolgreich den Datenkanal aushandelt.
Sat Nov 4 01:52:58 2006 [pid 5922] [user] FTP command: Client "1.2.3.4", "LIST" Sat Nov 4 01:53:58 2006 [pid 5922] [user] FTP response: Client "1.2.3.4", "425 Failed to establish connection."
Und hier haut die Verbindung daneben, der Server kann den Client nicht mehr erreichen.
*********************************
Sagt einem von Euch das etwas Näheres? (Abgesehen davon, daß der Rechner in der Zukunft arbeitet ;-) )
Wie ist deine Firewall eingestellt? Für einen Test kannst du ja mal die Firewall deaktivieren (in Yast) und neu starten. Wenn es danach plötzlich funktioniert, dann ist zumindest der Schuldige enttarnt. FTP ist ein notorisch übles Protokoll, was die Behandlung durch Firewalls betrifft. Da ein Steuer- und Datenkanal ausgehandelt werden können/müssen, ist die Zuordnung, welche Pakete zu einer FTP-Session gehören, nicht ganz trivial. Deshalb gibt es auch immer wieder Schwierigkeiten, wenn eine Firewall aktiv ist. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Hallo, Am Fre, 03 Nov 2006, Sandy Drobic schrieb:
Fritz Mundtart wrote: [..]
Sat Nov 4 01:52:58 2006 [pid 5922] [user] FTP command: Client "1.2.3.4", "PORT 1,2,3,4,194,44" Sat Nov 4 01:52:58 2006 [pid 5922] [user] FTP response: Client "1.2.3.4", "200 PORT command successful. Consider using PASV."
Client fällt also zurück auf das normale PORT Kommando, welches erfolgreich den Datenkanal aushandelt.
Sat Nov 4 01:52:58 2006 [pid 5922] [user] FTP command: Client "1.2.3.4", "LIST" Sat Nov 4 01:53:58 2006 [pid 5922] [user] FTP response: Client "1.2.3.4", "425 Failed to establish connection."
Und hier haut die Verbindung daneben, der Server kann den Client nicht mehr erreichen.
Genau.
FTP ist ein notorisch übles Protokoll, was die Behandlung durch Firewalls betrifft. Da ein Steuer- und Datenkanal ausgehandelt werden können/müssen, ist die Zuordnung, welche Pakete zu einer FTP-Session gehören, nicht ganz trivial. Deshalb gibt es auch immer wieder Schwierigkeiten, wenn eine Firewall aktiv ist.
Dafuer gibt's bei iptables (ipv4) das Modul ip_conntrack_ftp. -dnh -- Sufficiently advanced incompetence is indistinguishable from malice. -- dima
participants (4)
-
Andre Tann -
David Haller -
Fritz Mundtart -
Sandy Drobic