Dee
Anmeldungsdatum: 9. Februar 2006
Beiträge: 20087
Wohnort: Schwabenländle
|
Hallo, Und zwar kann ich nach dem erfolgreichen Login mit "ssh name@IP" 9-11 Zeichen eintippen, dann reagiert die Konsole nicht mehr. Eine Eingabe ist nicht möglich. Laut auth.log bin ich noch angemeldet. Konkret: Wenn ich "ssh dee@desktop" oder "ssh dee@127.0.0.1" oder "ssh dee@192.168.1.21" mache, kann ich ganz normal arbeiten. Wenn ich aber "ssh dee@77.xx.xx.xx" mache, dann hängt die Eingabe nach 9-11 Zeichen. Es ist egal, ob ich Unsinn in einer Zeile tippe oder einfach nur mehrfach Return ohne extra Eingabe. Meine Vermutung ist, dass es etwas mit der Verbindung ins Internet zurück in den Router zu tun hat. Der Router ist von o2 (Telefonica). Hat jemand eine Idee, was ich noch prüfen kann? Hintergrund: Ich nutze für den Support meiner Eltern diese Anleitung (hab ich mal vor X Jahren geschrieben). Nach dem Upgrade des Laptops meiner Eltern auf Ubuntu 18.04.1 habe ich nun Probleme, wenn ich mich per ssh zwischen den Geräten verbinden will. Das scheint aber gar nichts damit zu tun zu haben. Vorgestern hat das Reverse-VNC vom Laptop meiner Eltern (auswärts) auf meinen Desktop noch funktioniert. Jetzt ist der Unterschied, dass beides unter einem Dach am gleichen Router hängt. Gruß Dee
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
Dee schrieb: Meine Vermutung ist, dass es etwas mit der Verbindung ins Internet zurück in den Router zu tun hat.
Kannst Du danach (d. h. nach den 11 Zeichen) auf deinem Gerät, noch eingehende Datenpakete vom sshd-Port des Laptops deiner Eltern, sehen?
sudo tcpdump -c 100 -vvveni <Interface> src port 22
|
Dee
(Themenstarter)
Anmeldungsdatum: 9. Februar 2006
Beiträge: 20087
Wohnort: Schwabenländle
|
Nein. Nach einem sudo tcpdump -c 100 -vvveni wlp3s0 src port 22 dachte ich zuerst, dass es noch geht, aber die empfangene Daten sind von der falschen IP bzw. falsche Richtung: 06:24:52.925166 aa:aa:aa:aa:aa:aa > bb:bb:bb:bb:bb:bb, ethertype IPv4 (0x0800), length 102: (tos 0x10, ttl 63, id 32834, offset 0, flags [DF], proto TCP (6), length 88)
89.14.118.29.22 > 192.168.1.21.56024: Flags [P.], cksum 0xaefe (correct), seq 1996:2032, ack 953, win 291, options [nop,nop,TS val 8665359 ecr 8665357], length 36
// Hier bricht der Strom ab und geht irgendwann mal z.B. so weiter:
06:26:00.059344 aa:aa:aa:aa:aa:aa > bb:bb:bb:bb:bb:bb, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
192.168.1.21.22 > 115.238.245.4.53685: Flags [S.], cksum 0x065e (correct), seq 2771311466, ack 2902950520, win 28960, options [mss 1460,sackOK,TS val 8682143 ecr 2074777,nop,wscale 7], length 0 Gruß Dee
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
Dee schrieb:
// Hier bricht der Strom ab und geht irgendwann mal z.B. so weiter:
06:26:00.059344 aa:aa:aa:aa:aa:aa > bb:bb:bb:bb:bb:bb, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
192.168.1.21.22 > 115.238.245.4.53685: Flags [S.], cksum 0x065e (correct), seq 2771311466, ack 2902950520, win 28960, options [mss 1460,sackOK,TS val 8682143 ecr 2074777,nop,wscale 7], length 0
Welches Gerät hat die IP-Adresse 192.168.1.21 und lauscht auf dem Port 22 bzw. sendet von diesem Port 22 ein syn+ack an die chinesische IP-Adresse 115.238.245.4?
|
Akedia
Anmeldungsdatum: 3. Januar 2018
Beiträge: 83
|
IP Abuse Reports for 115.238.245.4: This IP address has been reported a total of 7626 times from 147 distinct sources. 115.238.245.4 was first reported on December 11th 2017, and the most recent report was 1 hour ago. https://www.abuseipdb.com/check/115.238.245.4 Das klingt nicht gut ...
|
Dee
(Themenstarter)
Anmeldungsdatum: 9. Februar 2006
Beiträge: 20087
Wohnort: Schwabenländle
|
@lubux: .21 ist mein Desktop. Heute hatte ich Verbindungen zu "183.230.146.26", was ebenfalls ein Abuse-Server ist: https://www.abuseipdb.com/check/183.230.146.26 Es gab aber jetzt seit 5 Minuten keine Aktivität mehr. Wie wahrscheinlich ist es, dass das Einfrieren bei ssh-Login etwas mit der Verbindung von meinem Rechner nach China zu tun hat? Wenn eher unwahrscheinlich mache ich einen zweiten Thread auf, wo wir uns mit dem Thema beschäftigen können. Wenn eher wahrscheinlich, machen wir hier weiter. (Z.B. wie ich erkennen kann, welcher Prozess die Daten sendet.) Gruß Dee
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
Dee schrieb: @lubux: .21 ist mein Desktop.
Lauscht dein Desktop (sshd) auf dem Port 22? ... und hast Du in deinem Router eine Portweiterleitung, zum Port 22 deines Desktops konfiguriert? Wie ist die Ausgabe von:
sudo netstat -tlpena | grep -i 22
?
|
Dee
(Themenstarter)
Anmeldungsdatum: 9. Februar 2006
Beiträge: 20087
Wohnort: Schwabenländle
|
Lauscht dein Desktop (sshd) auf dem Port 22? ... und hast Du in deinem Router eine Portweiterleitung, zum Port 22 deines Desktops konfiguriert?
Da ich Reverse VNC nutze, ist die Antwort ja. Die Idee ist ja, dass sich der Laptop meiner Eltern per SSH auf meinen Desktop verbinden kann. Daher ist es nicht außergewöhnlich, dass ggf. jemand anderes den Port scannt oder versucht dort einzudringen. Ungewöhnlicher fände ich es, wenn irgendein Prozess von meinem Laptop per SSH sich irgendwohin verbinden will. $ sudo netstat -tlpena | grep -i 22
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 22310 1165/sshd
tcp6 0 0 :::22 :::* LISTEN 0 22312 1165/sshd Gruß Dee
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
Dee schrieb: Daher ist es nicht außergewöhnlich, dass ggf. jemand anderes den Port scannt oder versucht dort einzudringen.
OK. Versuch mal auf deinem Gerät und auf dem Laptop deiner Eltern mit:
net.ipv4.tcp_ecn = 1
net.ipv4.tcp_ecn_fallback = 0
in der "/etc/sysctl.conf" und mit:
sudo sysctl -p
sudo iptables -I INPUT 1 -i wlp3s0 -p tcp --dport 22 --tcp-flags SYN SYN -m ecn ! --ecn-tcp-cwr -m state --state INVALID,NEW -j DROP
|
Dee
(Themenstarter)
Anmeldungsdatum: 9. Februar 2006
Beiträge: 20087
Wohnort: Schwabenländle
|
So, Problem gelöst. Das Problem war, dass ich mit Laptop und Desktop am gleichen Router bzw. im gleichen WLAN hänge. Es gibt dann eine Art Rückkoppelung, welche die Verbindung lahm legt. Wenn ich den Laptop z.B. über mein Handy ins Netz gehen lasse, funktioniert die SSH-Verbindung problemlos. Das zweite Problem mit dem chinesischen Server ist auch gelöst: Der tcpdump-Befehl oben liest nur meinen Rechner als Quelle auf, weil die Option "src" angegeben ist. Mit Wireshark bzw. ohne "src" sieht man sehr gut, dass zuerst die Anfrage von dem chinesischen Rechner an mich geht und mein Rechner dann höflich ablehnt. 😉 21:26:12.995836, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 242, id 54321, offset 0, flags [none], proto TCP (6), length 40)
180.101.88.222.41909 > 192.168.1.21.22: Flags [S], cksum 0x3431 (correct), seq 3918143322, win 65535, length 0
21:26:12.995872, ethertype IPv4 (0x0800), length 58: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 44)
192.168.1.21.22 > 180.101.88.222.41909: Flags [S.], cksum 0xf197 (correct), seq 2033008526, ack 3918143323, win 29200, options [mss 1460], length 0
21:26:13.242085, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 51, id 0, offset 0, flags [DF], proto TCP (6), length 40)
180.101.88.222.41909 > 192.168.1.21.22: Flags [R], cksum 0x342e (correct), seq 3918143323, win 0, length 0 Und es ist nicht ungewöhnlich, dass wenn man den Port 22 freigegeben hat, diverse Bots versuchen darauf zuzugreifen. Beide Problem haben sich also gelöst. Gruß Dee
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
Dee schrieb: Mit Wireshark bzw. ohne "src" sieht man sehr gut, dass zuerst die Anfrage von dem chinesischen Rechner an mich geht und mein Rechner dann höflich ablehnt. 😉 21:26:12.995872, ethertype IPv4 (0x0800), length 58: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 44)
192.168.1.21.22 > 180.101.88.222.41909: Flags [S.], cksum 0xf197 (correct), seq 2033008526, ack 3918143323, win 29200, options [mss 1460], length 0
Wenn Du das meinst, das ist keine höfliche Ablehnung. Das ist ein syn+ack (d. h. ja, ich lausche auf dem Port 22).
|