Hallo zusammen!
Seit dem ich über unsere neue WLAN-Verbindung (im Bürgernetz) im Internet unterwegs bin, gehen scp und rsync nicht mehr. scp meldet sich an, aber beim Start des Transfer bricht es mit einer Fehlermeldung "connection reset by peer" ab.
ssh dagegen geht einwandfrei und scp funktioniert auch über meine ISDN-Verbindung.
Ich habe den Verdacht, dass es mit einer zu kleinen MTU auf irgendeiner Zwischenstation zusammenhängt. Vielleicht werden die dazu nötigen ICMP-Pakete (MTU path discovery) auch von irgendeinem firewall weggeworfen.
Hat dazu jemand einen Tipp? Ohne scp und rsync bin ich irgendwie erschossen.
Danke schon mal!
Pitti
On 11.06.03 Martin Pitt (martin@piware.de) wrote:
Seit dem ich über unsere neue WLAN-Verbindung (im Bürgernetz) im Internet unterwegs bin, gehen scp und rsync nicht mehr. scp meldet sich an, aber beim Start des Transfer bricht es mit einer Fehlermeldung "connection reset by peer" ab.
ssh dagegen geht einwandfrei und scp funktioniert auch über meine ISDN-Verbindung.
Ich habe den Verdacht, dass es mit einer zu kleinen MTU auf irgendeiner Zwischenstation zusammenhängt. Vielleicht werden die dazu nötigen ICMP-Pakete (MTU path discovery) auch von irgendeinem firewall weggeworfen.
ssh -v oder Sniffen mit ethereal/tcpdump ? Sieht man da was?
H.
Hi!
Am 2003-06-11 18:29 +0200 schrieb Hilmar Preusse:
On 11.06.03 Martin Pitt (martin@piware.de) wrote:
Seit dem ich über unsere neue WLAN-Verbindung (im Bürgernetz) im Internet unterwegs bin, gehen scp und rsync nicht mehr. scp meldet sich an, aber beim Start des Transfer bricht es mit einer Fehlermeldung "connection reset by peer" ab.
ssh dagegen geht einwandfrei und scp funktioniert auch über meine ISDN-Verbindung.
Ich habe den Verdacht, dass es mit einer zu kleinen MTU auf irgendeiner Zwischenstation zusammenhängt. Vielleicht werden die dazu nötigen ICMP-Pakete (MTU path discovery) auch von irgendeinem firewall weggeworfen.
ssh -v oder Sniffen mit ethereal/tcpdump ? Sieht man da was?
Ich habe nichts auffälliges gesehen:
$ scp -v joke pitt@paprika.inf.tu-dresden.de: [...] debug1: Authentication succeeded (publickey). debug1: fd 4 setting O_NONBLOCK debug1: fd 5 setting O_NONBLOCK debug1: channel 0: new [client-session] debug1: Entering interactive session. debug1: Sending command: scp -v -t . debug1: channel 0: request exec debug1: channel 0: open confirm rwindow 0 rmax 32768 debug1: channel_free: channel 0: client-session, nchannels 1 debug1: fd 0 clearing O_NONBLOCK debug1: fd 1 clearing O_NONBLOCK Read from remote host paprika.inf.tu-dresden.de: Connection reset by peer debug1: Transferred: stdin 0, stdout 0, stderr 75 bytes in 0.1 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 556.0 debug1: Exit status -1 lost connection
Die Anmeldung ist erfolgreich aber beim Transferstart geht dann irgendwas schief. Ich habe auf unserem WLAN-Server daneben mal ein
tcpdump -i eth0 | grep paprika.inf.tu-dresden.de
laufen lassen und das log mal angehängt. Viel kann ich allerdings nicht da rauslesen.
Danke schon mal für jede Hilfe!
Pitti
On 12.06.03 Martin Pitt (martin@piware.de) wrote:
Am 2003-06-11 18:29 +0200 schrieb Hilmar Preusse:
On 11.06.03 Martin Pitt (martin@piware.de) wrote:
Moin,
Ich habe den Verdacht, dass es mit einer zu kleinen MTU auf irgendeiner Zwischenstation zusammenhängt. Vielleicht werden die dazu nötigen ICMP-Pakete (MTU path discovery) auch von irgendeinem firewall weggeworfen.
Schon mal an der MTU herumgespielt?
ssh -v oder Sniffen mit ethereal/tcpdump ? Sieht man da was?
Ich habe nichts auffälliges gesehen:
$ scp -v joke pitt@paprika.inf.tu-dresden.de: [...] debug1: fd 0 clearing O_NONBLOCK debug1: fd 1 clearing O_NONBLOCK Read from remote host paprika.inf.tu-dresden.de: Connection reset by peer
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Schieb doch auch mal den sshd mit -d an. Vorsicht, dann nimmt er nur noch eine Verbindung an.
H.
Hi!
Am 2003-06-17 8:28 +0200 schrieb Hilmar Preusse:
Ich habe den Verdacht, dass es mit einer zu kleinen MTU auf irgendeiner Zwischenstation zusammenhängt. Vielleicht werden die dazu nötigen ICMP-Pakete (MTU path discovery) auch von irgendeinem firewall weggeworfen.
Schon mal an der MTU herumgespielt?
Ja, ich habe sie auf beiden Enden auf aberwitzig kleine Größen (bis runter auf 200) gedrückt, hilft nischt.
Schieb doch auch mal den sshd mit -d an. Vorsicht, dann nimmt er nur noch eine Verbindung an.
Ich habe mal zum Vergleichen das log ssh-fails.txt (von "donald" zuhause in die Uni, was nicht geht) und ssh-works.txt (von einem anderen Rechner "web08", wo es geht) angehängt. Vielleicht wird ja jemand schlau daraus.
Auch ssh selbst geht nicht, wenn ich ihm einen Befehl mitgebe. Hier sind die "Screenshots":
----------- root@paprika:~# sshd -d -d -d 2> sshd-fails.txt ----------- martin@donald:~> ssh pitt@paprika.inf.tu-dresden.de true Read from remote host paprika.inf.tu-dresden.de: Connection reset by peer ----------- [sshd server terminiert auf paprika, weil er im Debug-Modus ist]
root@paprika:~# sshd -d -d -d 2> sshd-works.txt ----------- mpitt@web08:~> ssh pitt@paprika.inf.tu-dresden.de true pitt@paprika.inf.tu-dresden.de's password: debug3: Copy environment: NNTPSERVER=news.inf.tu-dresden.de debug3: Copy environment: PATH=/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/games debug3: Copy environment: LANG=de_DE@euro debug3: Copy environment: MAIL=/var/mail/pitt Environment: USER=pitt LOGNAME=pitt HOME=/home/users/pitt PATH=/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/games MAIL=/var/mail/pitt SHELL=/bin/bash SSH_CLIENT=217.11.48.108 1432 22 NNTPSERVER=news.inf.tu-dresden.de LANG=de_DE@euro debug3: channel_close_fds: channel 0: r -1 w -1 e -1 ----------- [sshd server terminiert auf paprika, weil er im Debug-Modus ist] -----------
scp2 und ssh2, die kommerziellen Versionen (www.ssh.com) funktionieren übrigens einwandfrei.
Danke schon mal für Hilfe!
Pitti -- Martin Pitt home: www.piware.de eMail: martin@piware.de
Hallo Martin,
versuche doch mal, auf beiden Seiten die gleiche Version von ssh einzusetzen.
Am 17. Juni 2003 schrieb Martin Pitt:
Read from remote host paprika.inf.tu-dresden.de: Connection reset by peer
Komischerweise behaupten das beide Seiten. Guck doch mal mit einem Sniffer, welche Seite die Verbindung beendet. Könnte vielleicht auch eine falsch konfigurierte Brandmauer sein.
Torsten
Hallo Torsten!
Am 2003-06-17 20:43 +0200 schrieb Torsten Werner:
Hallo Martin,
versuche doch mal, auf beiden Seiten die gleiche Version von ssh einzusetzen.
Auf beiden Seiten läuft die openssh-Version aus Debian/Woody.
Komischerweise behaupten das beide Seiten. Guck doch mal mit einem Sniffer, welche Seite die Verbindung beendet. Könnte vielleicht auch eine falsch konfigurierte Brandmauer sein.
Kann auch durchaus sein, dass es an der Firewall liegt. Das lustige ist ja auch, dass es funktioniert, wenn ich vom Bürgernetz auf meine alte Internet-Verbindung über T-ISDN schalte. Irgendwie muss es also am Netz liegen. Andererseits geht interaktives ssh und das kommerzielle ssh2 auch, also gibt es auch eine Lösung, wo der Unterschied der ISPs keine Rolle spielt.
Ich versuche also momentan rauszufinden, wo genau der Unterschied zwischen 'ssh host' und 'ssh host command' liegt; ersteres geht, das andere nicht. Zum Verrücktwerden...
Pitti
Hallo Martin,
Am 18. Juni 2003 schrieb Martin Pitt:
Auf beiden Seiten läuft die openssh-Version aus Debian/Woody.
Ja, aber eben nicht die gleiche Version, wenn die Angaben in der Logdatei stimmen.
Torsten
lug-dd@mailman.schlittermann.de
-
Hilmar Preusse -
Martin Pitt -
Torsten Werner