moin, ich hab gerade meinen Server mit dyndns versorgt. remote mit vnc über tunnel 5900:dyndns-host:5910 klappt prima genauso http. bei ssh -L 21:dyndns-host:21 funtioniert nicht, ssh meckert, das der port schon benutzt wird. ssh -L 4012:dyndns-host:21 geht erst einmal, aber wenn ich dann mit ftp localhost 4012 versuche ftp zu benutzen kann ich mich zwar einloggen, aber ein ls führt zu folgendem Fehler: ftp> ls 229 Extended Passive mode OK (|||29530|) 500 I won't open a connection to 127.0.0.1 (only to 217.229.111.244) 500 I won't open a connection to 127.0.0.1 (only to 217.229.111.244) ftp: bind: Address already in use da ich nicht genau weiss, wie ftp funktioniert weiss ich jetzt nicht weiter. eine Möglichkeit die ich nicht wirklich möchte wäre natürlich unter FW_services_ext ftp in SuSEfirewall2 freizuschalten, dann kann ich mich direkt bei "dyndns-host" per ftp eiloggen und alles funzt. ich würde allerdings vorziehen nur ssh dort stehen zu haben. Frage: wer hilft mir weiter tschüss Didi
Dietrich Restemeyer wrote:
moin, ich hab gerade meinen Server mit dyndns versorgt. remote mit vnc über tunnel 5900:dyndns-host:5910 klappt prima genauso http.
bei ssh -L 21:dyndns-host:21 funtioniert nicht, ssh meckert, das der port schon benutzt wird.
ssh -L 4012:dyndns-host:21 geht erst einmal, aber wenn ich dann mit ftp localhost 4012 versuche ftp zu benutzen kann ich mich zwar einloggen, aber ein ls führt zu folgendem Fehler:
... warum brauchst Du ftp? ftp ist UNSICHER, weil das Passwort im Klartext übertragen wird. Ggf. geht ja auch scp (Linux) oder pscp (Windows) für Dich? Wenn Du einen Windows-Client hast, ist winscp eine sehr gute Variante (weil so schön grafisch ;-). Viel Erfolg Joachim
On Sunday 01 August 2004 23:46, Dietrich Restemeyer wrote:
da ich nicht genau weiss, wie ftp funktioniert weiss ich jetzt nicht weiter. eine Möglichkeit die ich nicht wirklich möchte wäre natürlich unter FW_services_ext ftp in SuSEfirewall2 freizuschalten, dann kann ich mich direkt bei "dyndns-host" per ftp eiloggen und alles funzt. ich würde allerdings vorziehen nur ssh dort stehen zu haben.
Frage: wer hilft mir weiter
Ich weiß zwar keine direkte Lösung, aber vielleicht kann ich einen Ansatz liefern. Ich hab letztens an meiner Firewall gebastelt und mich da auch mit ftp auseinandersetzen müssen. Port 21 ist nur der Port auf dem ein Connect hergestellt wird. Die Daten fließen dann über einen anderen. Früher war das anscheinend Port 20, dieser wird aber jetzt normalerweise nicht mehr benutzt. Statt dessen wird ein Port zwischen 1024 und 65535, in manchen Fällen kann es auch ein kleinerer Bereich zwischen 65xxx und 65535 sein. Naja, auf jeden Fall ging an der Stelle bei mir das Problem los. Port 21, ist klar, aber danach wird es ein wenig tricky. Wenn Du also mit Deinem forwarding einen Connect zu einem ftp-Server bekommst und danach nichts mehr geht, wird das wohl der Grund sein. MfG Marco
Am Sonntag, 1. August 2004 23:46 schrieb Dietrich Restemeyer:
moin, ich hab gerade meinen Server mit dyndns versorgt. remote mit vnc über tunnel 5900:dyndns-host:5910 klappt prima genauso http.
bei ssh -L 21:dyndns-host:21 funtioniert nicht, ssh meckert, das der port schon benutzt wird.
ssh -L 4012:dyndns-host:21 geht erst einmal, aber wenn ich dann mit ftp localhost 4012 versuche ftp zu benutzen kann ich mich zwar einloggen, aber ein ls führt zu folgendem Fehler:
Hallo Dietrich, Für FTP Tunneling brauchst du den kommerziellen SSH-client von ftp.ssh.com. Das Problem ist, dass FTP für Datenverbindungen einen *Rückwärtskanal* öffnet (vom Server zum Client zurück), und von dem weiss (natürlich) der SSH-Tunnel nichts. Dummerweise werden die Ports für die Rückverbindung erst *während* der FTP-Sitzung festgelegt. Dies wird z.B. von FXP ausgenutzt, um Daten zwischen zwei FTP-Servern hin und herzuschieben. FXP funktioniert aber nur bei FTP-Servern, die für die PORT-Anweisung "fremde" IP-Adressen akzeptieren, was eine Sicherheitslücke darstellt. Der SSH-client von SSH.com (kostenlos, aber keine open source) kann die Kontrollverbindung "abhören" und bei einer entsprechenden "PORT" Anweisung auf Port 21 startet er automatisch einen zweiten SSH-Tunnel. Du kannst dir das tar.gz einfach downloaden und mit "./configure ; make ; su -c 'make install'" installieren. Er installiert dann in /usr/local/bin Programme wie "ssh2", "ssh2-keygen", usw. und Links zu "ssh" usw. Ich würde danach noch in /usr/local/bin und .../sbin die Links ohne die 2 am Ende löschen, damit für normale SSH-Befehle immer noch das OpenSSH von Linux verwendet wird. -- Dipl.-Ing. Jens Benecke http://www.hitchhikers.de - Europas kostenlose Mitfahrzentrale seit 1998 http://www.rb-hosting.de - Webhosting mit Extras - PHP ab €9 - SSH ab €19 http://www.spamfreemail.de - 100% saubere Postfächer, garantiert!
Dietrich Restemeyer wrote:
moin, ich hab gerade meinen Server mit dyndns versorgt. remote mit vnc über tunnel 5900:dyndns-host:5910 klappt prima genauso http.
bei ssh -L 21:dyndns-host:21 funtioniert nicht, ssh meckert, das der port schon benutzt wird.
ssh -L 4012:dyndns-host:21 geht erst einmal, aber wenn ich dann mit ftp localhost 4012 versuche ftp zu benutzen kann ich mich zwar einloggen, aber ein ls führt zu folgendem Fehler:
ftp> ls 229 Extended Passive mode OK (|||29530|) 500 I won't open a connection to 127.0.0.1 (only to 217.229.111.244) 500 I won't open a connection to 127.0.0.1 (only to 217.229.111.244) ftp: bind: Address already in use
da ich nicht genau weiss, wie ftp funktioniert weiss ich jetzt nicht weiter. eine Möglichkeit die ich nicht wirklich möchte wäre natürlich unter FW_services_ext ftp in SuSEfirewall2 freizuschalten, dann kann ich mich direkt bei "dyndns-host" per ftp eiloggen und alles funzt. ich würde allerdings vorziehen nur ssh dort stehen zu haben.
Hi, läuft bei Dir der inetd? Kannst Du mit "rcinetd status" abfragen. Wenn ja, dann check mal /etc/inetd.conf, ob der auch auf ftp lauscht (lt. /etc/services sollte das Port 21 sein). Im Prinzip kann (ja sollte) man hier alle unnötigen Dienste wie ftp, login etc. deaktiven, indem man sie einfach in /etc/inetd.conf kommentiert. Danach noch "rcinetd restart" ausführen und schon sollte der Port frei sein. Wir machen hier alles per "ssh", "scp" und "rsync -e ssh". inetd bedient hier lediglich zwei interne Dienste, der Rest ist komplett deaktiviert. Viele Grüße Andreas
participants (5)
-
Andreas Loebel -
Dietrich.Restemeyer＠t-online.de -
Jens Benecke -
Joachim Kieferle -
Marco Röben