Zugriff auf Clients im gleichen Netz nicht möglich

matthias182
Goto Top
Hallo zusammen,

ich hoffe, ich werde nicht gesteinigt, aber ich habe vermutlich ein ganz triviales Problem, aber ich kann die Lösung bzw. die Ursache einfach nicht finden.

In meinem Heimnetzwerk habe ich generell verschiedene VLANS konfiguriert, wobei ich der Meinung bin, dass dies hier keine Rolle spielt. Es sollte nur um das VLAn gehen, in dem alle meine Clients sind.

Ich habe zwei Rechner im Netzwerk, beide beziehen eine IP aus dem VLAN 10 (per DHCP). Dazu habe ich dann noch weitere Clients im selben Netzwerk, wie einen kleinen Proxmox Server oder ein Synology NAS.

Das Problem stellt sich wie folgt dar. Von einem Rechner aus kann ich problemlos per Browser auf die Weboberflächen der Clients und auch die Applikationen auf den Proxmox Containern/VMs zugreifen. Auch ein Zugriff per SSH (Putty) auf alle Container/VMs und die Clients selber ist von dort möglich. Beim zweiten Rechner geht ebenfalls der Zugriff über den Browser allerdings sind Zugriffe per SSH blockiert. Egal auf welchen Client oder auch Container/VM ich zugreifen möchte ich erhalte einen Fehler.

Aus meiner Sicht beziehen auch die Clients eine IP aus dem VLAN 10, somit sollte das Routing theoretisch kein Thema darstellen, vermutlich liegt da aber doch irgendwo das Problem.

Könnt ihr mir da ein wenig helfen, wie ich die Ursache identifizieren kann?


Danke und Gruß
Matthias

Content-Key: 2591406421

Url: https://administrator.de/contentid/2591406421

Ausgedruckt am: 24.05.2022 um 20:05 Uhr

Mitglied: lcer00
lcer00 25.04.2022 um 08:19:39 Uhr
Goto Top
Hallom
Zitat von @Matthias182:

Beim zweiten Rechner geht ebenfalls der Zugriff über den Browser allerdings sind Zugriffe per SSH blockiert. Egal auf welchen Client oder auch Container/VM ich zugreifen möchte ich erhalte einen Fehler.
dass schließt ein Netzwerkproblem aus. HTTP und SSH sind beides Protokolle die auf TCP aufsetzten und wenn eins davon geht, sollte auch das andere funktionieren. Es sei dann, eine Firewall auf Client oder Server blockiert bestimmte IPs. Außerdem gibt es da noch diverse Blockiermöglichkeiten am SSH-Server. Welche Fehlermeldung wird denn angezeigt?

Grüße

lcer
Mitglied: Matthias182
Matthias182 25.04.2022 um 08:34:13 Uhr
Goto Top
Also Putty zeigt bei allen Clients die Meldung "Network error - permission denied". Dann nutze ich noch einen DB GUI Tool, da kommt als Antwort "Can't connect to server on 192.168.10.7 (10013).
Mitglied: lcer00
lcer00 25.04.2022 um 08:40:26 Uhr
Goto Top
Hallo,
Zitat von @Matthias182:

Also Putty zeigt bei allen Clients die Meldung "Network error - permission denied". Dann nutze ich noch einen DB GUI Tool, da kommt als Antwort "Can't connect to server on 192.168.10.7 (10013).
"Permission denied" bedeutet ja "Erlaubnis verweigert" - das heißt, die Verbindung wurde angefragt und vom Server aktiv zurückgewiesen: Das spricht für ein Pronbem mit SSH und eher nicht die Firewall, da würde normalerweise die Verbindung ins Leere laufen.

Wie verbindest Du Dich? per Password oder per Zertifikat?

Grüße

lcer
Mitglied: Matthias182
Matthias182 25.04.2022 um 08:43:20 Uhr
Goto Top
Per Passwort
Mitglied: lcer00
lcer00 25.04.2022 um 08:52:34 Uhr
Goto Top
Zitat von @Matthias182:

Per Passwort

Dann würde ich als erstes mal die SSH-Server-Logs ansehen. Da müssten genauere Fehlermeldungen drinstehen. Überprüf auch mal die verwendeten SSH-Version auf Server und Client(Putty) und versuch mal alternativ die Verbindung vom Windows-OpenSSH, falls Du von einer Windows-Maschine aus zugreifst.

Grüße

lcer
Mitglied: Matthias182
Matthias182 25.04.2022 um 08:56:06 Uhr
Goto Top
Bist du sicher? Ich nutze ja auch parallel dieses DB GUI Tool (HeidiSQL) und das nutzt doch kein SSH für die Verbindung, oder?
Mitglied: lcer00
lcer00 25.04.2022 um 08:58:18 Uhr
Goto Top
Hallo,
Zitat von @Matthias182:

Bist du sicher? Ich nutze ja auch parallel dieses DB GUI Tool (HeidiSQL) und das nutzt doch kein SSH für die Verbindung, oder?

doch, macht es: https://www.heidisql.com/help.php#connecting

Grüße

lcer
Mitglied: aqui
aqui 25.04.2022 aktualisiert um 09:17:24 Uhr
Goto Top
somit sollte das Routing theoretisch kein Thema darstellen,
Das kann man so nicht sagen, denn nur mit einer simplen Adresse allein ist es bekanntlich nicht getan ! Weisst du ja auch selber...
Entscheidend für ein sauberes Routing im VLAN Umfeld ist immer ob diese Clients auch ein korrektes Default Gateway beziehen !! Dann sind Ping und Traceroute immer deine besten Freunde um die IP Connectivity zwischen unterschiedlichen IP Segmenten wasserdicht zu verifizieren !
Wenn dann einzelnen Anwendungen nicht erreichbar sind ist der Fehler in der Regel zu 98% die lokale Firewall auf den Geräten, eine Blocking Regel in der Firewall oder eine Router Accessliste ! ;-) face-wink
Zum Rest hat Kollege @lcer00 oben schon alles gesagt.
Mitglied: Matthias182
Matthias182 25.04.2022 um 09:45:08 Uhr
Goto Top
Das macht Sinn, dann lass uns da mal anfangen. Ich nehme mal eine der VMs unter Proxmox als Beispiel. Der Ping funktioniert vom Rechner zur VM:


Und TRACERT liefert:

Da fällt mit auf, dass der Weg direkt zum Server geht, ohne Standard-Gateway dazwischen. Ist das richtig im Selben VLAN?
Mitglied: Matthias182
Matthias182 25.04.2022 um 10:06:00 Uhr
Goto Top
Wenn ich dann in die log.auth schaue finde ich zu SSH dort nur:

2022-04-25 10_05_27-window
Mitglied: lcer00
lcer00 25.04.2022 um 10:09:31 Uhr
Goto Top
Hallo,
Zitat von @Matthias182:

Wenn ich dann in die log.auth schaue finde ich zu SSH dort nur:

2022-04-25 10_05_27-window
Verbindest Du Dich auch auf Port 22?

Grüße

lcer
Mitglied: Matthias182
Matthias182 25.04.2022 um 10:14:15 Uhr
Goto Top
Ja, natürlich :-) face-smile
Mitglied: lcer00
lcer00 25.04.2022 um 10:23:01 Uhr
Goto Top
Zitat von @Matthias182:

Ja, natürlich :-) face-smile

Na dann zeig mal die Ausgabe von ssh in der Kommandozeile:

Ach ja, was für ein Switch ist das?

Grüße

lcer
Mitglied: Matthias182
Matthias182 25.04.2022 um 10:27:36 Uhr
Goto Top
Da kommt fast das gleiche bei raus:

ssh: connect to host 192.168.10.115 port 22: Permission denied

Der Switch ist ein Cisco SG200-26P
Mitglied: radiogugu
radiogugu 25.04.2022 um 11:07:09 Uhr
Goto Top
Zitat von @Matthias182:
Da fällt mit auf, dass der Weg direkt zum Server geht, ohne Standard-Gateway dazwischen. Ist das richtig im Selben VLAN?

Jap. Im selben Netzwerk wird das Standardgateay nicht befragt. Es muss ja nichts geroutet werden.

Sind denn nu die Firewalls der PC / VM entsprechend offen für die Zugriffe, welche du versuchst zu unternehmen?

Gruß
Marc
Mitglied: lcer00
lcer00 25.04.2022 aktualisiert um 11:14:52 Uhr
Goto Top
Hallo,

dann poste mal vom Server die /etc/ssh/sshd_config

Und was ist mit den ssh-Versionen?

Grüße

lcer
Mitglied: lcer00
lcer00 25.04.2022 um 11:38:23 Uhr
Goto Top
Ohne weitere infos kann man nur raten, aber:

zu den Versionen:

SHA-1 wurde 2021 zur Verwendung mit SSH deaktiviert.
https://www.openssh.com/releasenotes.html

damit passt, sind folgende Versionen erforderlich:

Putty >= 0.75
und OpenSSH >= 8.8


Grüße

lcer
Mitglied: Matthias182
Matthias182 25.04.2022 um 11:39:39 Uhr
Goto Top
Auf dem Server sollte keine Firewall aktiv sein. Sudo ufw status liefert nur: "ufw: Befehl nicht gefunden". Gibt es noch andere Firewalls?

SSH Versionen:
Windows(Client): OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2
Linux(Server):
2022-04-25 11_37_12-window

Und hier der Auszug aus der Config:
2022-04-25 11_33_49-window

2022-04-25 11_34_10-window

2022-04-25 11_34_30-window
Mitglied: Matthias182
Matthias182 25.04.2022 um 11:45:56 Uhr
Goto Top
Putty habe ich Version 0.76
Mitglied: lcer00
lcer00 25.04.2022 aktualisiert um 13:43:07 Uhr
Goto Top
Nur so der Vollständigkeit halber: bei PermitRootLogin=yes kann man sich per Root nicht anmelden. Du verwendest doch einen anderen User?

Schau sonst nochmal Protokolldateien auf dem Server an.

Grüße

lcer
Mitglied: Matthias182
Matthias182 25.04.2022 um 13:05:45 Uhr
Goto Top
Ich verwende zum Testen im Moment root.

Aber meint PermitRootLogin = yes nicht genau das Gegenteil, also ich kann mich mit root anmelden?
Mitglied: aqui
aqui 25.04.2022, aktualisiert am 05.05.2022 um 23:29:51 Uhr
Goto Top
Könnte ggf. auch ein Kex Exchange Fehler sein wie Kollege @lcer00 oben schon sagt, aber dann würde man eine deutliche SSH Fehlermeldung sehen:

Cisco, Mikrotik, pfSense site-to-site VPN with dynamic routing

Mit PuTTY in der aktuellen Version passiert das normalerweise nicht.
Der Switch ist ein Cisco SG200-26P
Das ist auch Unsinn, denn der SG200 supportet generell keinen SSH oder Telnet CLI Zugriff ! Der SG200 kann nur WebGUI und sonst nix.
CLI Zugang mit SSH/Telnet gibts erst ab dem SG300 bzw. den SGx50 Modellen !
Und auch da muss man es vorher im Menü Security -> TCP/UDP Services aktivieren, denn im Default ist es inaktiv.
ssh
Handbuch lesen hilft hier, wie immer. ;-) face-wink
Gibt es noch andere Firewalls?
Solltest du als Linux Profi eigentlich wissen !! 🧐 iptables und nftables
sudo iptables -L -v -n
sudo nft list tables
Mitglied: Matthias182
Matthias182 25.04.2022 um 13:19:26 Uhr
Goto Top
Ich glaube das mit dem Switch war schlicht ein Missverständnis. Mit dem versuche ich mit nicht zu verbinden, schon gar nicht per SSH. Icer hatte danach gefragt.

iptables liefern nur eine leere Liste, nftables gibt es nicht.
Mitglied: aqui
Lösung aqui 25.04.2022 aktualisiert um 13:26:34 Uhr
Goto Top
Lass ein sudo tcpdump -v port 22 laufen und sieh dir mal an ob am Server überhaupt SSH Pakete vom Client ankommen !
Oder alternativ tcpdump -v port 22 and host <ip_client> dann zeigt dir tcpdump einzig nur den SSH Traffic des Clients mit der IP <ip_client>.
(Ggf. vorher apt-install tcpdump sofern nicht installiert.)
Mitglied: Matthias182
Matthias182 25.04.2022 um 13:28:03 Uhr
Goto Top
Das mit dem Switch erscheint mir die falsche Richtung zu sein. Wie gesagt, ein anderer Rechner am selben Switch, im selben VLAN funktioniert ohne Probleme.
Mitglied: aqui
aqui 25.04.2022 aktualisiert um 13:40:00 Uhr
Goto Top
Genau deshalb ja tcpdump und/oder Wireshark um zu sehen ob überhaupt SSH Traffic dieses Clients ins Netzwerk geht.
https://phoenixnap.com/kb/ssh-permission-denied-publickey
Mitglied: lcer00
lcer00 25.04.2022 um 13:43:30 Uhr
Goto Top
Zitat von @Matthias182:

Ich verwende zum Testen im Moment root.

Aber meint PermitRootLogin = yes nicht genau das Gegenteil, also ich kann mich mit root anmelden?

Sorry, da habe ich zu schnell getippt.....
Mitglied: Matthias182
Matthias182 25.04.2022 um 14:01:17 Uhr
Goto Top
Also tcpdump erkennt auf dem Port 22 keinen Datenverkehr. Habe sowohl Putty als auch openSSH probiert.
Mitglied: aqui
aqui 25.04.2022 aktualisiert um 14:54:39 Uhr
Goto Top
Dann kommt da auch am SSH Zielserver gar nichts an. Logisch das es dann in die Hose gehen muss. Wenn man den Wasserhahn am Gartenschlauch nicht aufdreht kommt am anderen Ende auch kein Wasser raus... ;-) face-wink
Du musst also herausfinden warum der Client gar keinen SSH Traffic sendet. Gateway Fehler, Lokale Firewall, Router ACL, usw.
Mitglied: Matthias182
Matthias182 25.04.2022 um 15:34:36 Uhr
Goto Top
Das ist leider alles nicht so mein Steckenpferd. Könnt ihr mich da noch etwas an die Hand nehmen? Wo kann ich am besten anfangen?
Mitglied: Milord
Milord 25.04.2022 um 20:35:47 Uhr
Goto Top
Gateway Fehler, Lokale Firewall, Router ACL, usw.
Geprüft?
Mitglied: lcer00
lcer00 25.04.2022 um 22:11:14 Uhr
Goto Top
Hallo,
Zitat von @Matthias182:

Das ist leider alles nicht so mein Steckenpferd. Könnt ihr mich da noch etwas an die Hand nehmen? Wo kann ich am besten anfangen?

Poste mal die Ausgabe von > tracert 192.168.10.115

Grüße

lcer
Mitglied: Matthias182
Matthias182 26.04.2022 um 06:33:15 Uhr
Goto Top
Der Traceroute ist leider sehr schmal:

Mitglied: Matthias182
Matthias182 26.04.2022 um 06:51:01 Uhr
Goto Top
Ich habe jetzt mal mit Wireshark geschaut, was hier passiert und da sehe ich scheinbar keinen Datenverkehr der auf SSH hindeutet, wenn ich versuche die Verbindung auszubauen:

2022-04-26 06_49_28-window

2022-04-26 06_50_45-window
Mitglied: aqui
aqui 26.04.2022 um 07:51:25 Uhr
Goto Top
und da sehe ich scheinbar keinen Datenverkehr der auf SSH hindeutet
Da hast du Recht ! Hatte der tcpdump Trace ja auch schon gezeigt. Da gibt es weit und breit keinerlei SSH und wo gar kein SSH ist, kann auch kein SSH funktionieren ! Einfache Logik... ;-) face-wink
Jetzt ist es an dir herauszubekommen warum der SSH Traffic da nicht ankommt.
Wie oben bereits gesagt: "Gateway Fehler, Lokale Firewall, Router ACL, usw. Geprüft?"
Mitglied: Matthias182
Matthias182 26.04.2022 um 08:04:20 Uhr
Goto Top
Also die lokale Firewall habe ich jetzt deaktiviert. Das hilft nicht.

Im Router habe ich nichts dergleichen konfiguriert, aber zur Sicherheit, wo finde ich die ACL's bei Mikrotik? Sind das unter Firewall die Adress Lists?

Gateway Fehler? Der Ping geht ja durch und per Browser geht es auch, müssten die dann nicht auch hängen bleiben?
Mitglied: lcer00
lcer00 26.04.2022 um 08:23:39 Uhr
Goto Top
Hallo,
Zitat von @aqui:

und da sehe ich scheinbar keinen Datenverkehr der auf SSH hindeutet
Da hast du Recht ! Hatte der tcpdump Trace ja auch schon gezeigt. Da gibt es weit und breit keinerlei SSH und wo gar kein SSH ist, kann auch kein SSH funktionieren ! Einfache Logik... ;-) face-wink
Jetzt ist es an dir herauszubekommen warum der SSH Traffic da nicht ankommt.
Wie oben bereits gesagt: "Gateway Fehler, Lokale Firewall, Router ACL, usw. Geprüft?"

Sind das die Wireshark-Traces vom Client oder vom Server?

Grüße

lcer
Mitglied: aqui
aqui 26.04.2022 aktualisiert um 08:28:14 Uhr
Goto Top
aber zur Sicherheit, wo finde ich die ACL's bei Mikrotik? Sind das unter Firewall die Adress Lists?
Ja und außerdem das dortige Regelwerk. Ein WinBox Screenshot würde hier allen helfen und ganz besonders dir. ;-) face-wink
Mitglied: Matthias182
Matthias182 26.04.2022 um 08:50:18 Uhr
Goto Top
Es handelt sich um den Mitschnitt vom Client. Server dachte ich, macht wenig Sinn, da wir schon gesehen haben, das dort nichts ankommt.

Hier die Screenshots der Firewall. Hier bleibe ich aber skeptisch, weil der eine Rechner im gleichen Netz funktioniert und ich keine spezifischen Regeln für einzelne Clients habe.

2022-04-26 08_47_12-window

2022-04-26 08_47_30-window
Mitglied: lcer00
Lösung lcer00 26.04.2022 um 09:10:47 Uhr
Goto Top
Hallo,

also wenn das ein Mitschnitt vom Client ist, stellt sich die Frage, warum dort kein SSH-Traffic zu sehen ist. Das hat jedenfalls ausschließlich etwas mit dem Client zu tun! Die Microtik?-Firewall kann es dann nicht sein. Es müssten je wenigsten die ausgehenden Paktete mit Ziel auf Port 22 zu sehen sein!

Aus dem Bauch heraus würde ich als erstes folgendes überprüfen:
  • ausgehende (nicht eingehenden!!!!) Windows-Firewall-Regeln
  • hast Du mehrere Netzwerkschnittstellen am Client ( > ipconfig /all )
  • so doof das klingt: Stimmen die IPs ??
  • Stimmt das, dass Du wie oben beschrieben vom Client auf das Webinterface des Servers zugreifen kannst?

Grüße

lcer
Mitglied: Reini82
Reini82 26.04.2022 um 09:24:57 Uhr
Goto Top
Hi,

mal eine andere Frage verwendest du 2 Rechner an 2 verschiedenen Ports? Wenn ja hast du den Funktionierenden Rechner mal an den Switch Port des 2. Rechners angeschlossen und getestet ob du eine Verbindung bekommst?

Wenn ja Problem am Rechner 2, wenn nein Problem am Switchport.

Gruß
Mitglied: aqui
aqui 26.04.2022 aktualisiert um 09:31:04 Uhr
Goto Top
Sie kann es auch grundsätzlich nicht sein wenn es denn stimmt das, wie der TO sagt, er sich mit SSH Client und Server in einem gemeinsamen L2 LAN Segment befindet. Dann ist ja so oder so niemals ein Router, Firewall, ACL oder sonstwas involviert, da Traffic innerhalb eines gemeinsamen IP Netzes bekanntlich direkt von Endgerät zu Endgerät geht ohne etwas dazwischen.
Es kann dann einzig und allein ausschliesslich nur die lokale Firewall auf den jeweiligen Endgeräten sein, denn nur die sind ja dann überhaupt beteiligt.
Oder am Switch die falsche VLAN Zuordnung (PVID) wie Kollege @Reini82 oben richtig sagt.
Dagegen spricht dann aber das, wie der TO sagt, Web Traffic funktioniert und nur SSH betroffen ist. Bei einer falschen VLAN Zuordnung (PVID) wäre sämtlicher Traffic betroffen.
Mitglied: lcer00
Lösung lcer00 26.04.2022 um 09:29:45 Uhr
Goto Top
Hallo,
Zitat von @aqui:
Es kann dann einzig und allein ausschliesslich nur die lokale Firewall auf den jeweiligen Endgeräten sein, denn nur die sind ja dann überhaupt beteiligt.
Da fällt mir noch ein, dass einige Drittanbieter-Endpunkt-Firewall-Lösungen gelegentlich SSH-Verkehr im Netzwerk grundsätzlich als verdächtig einstufen und blocken. Falls da so etwas zusätzlich zur Windows-Firewall installiert ist: Protokollierung aktivieren und Protokolle lesen.

Grüße

lcer
Mitglied: Matthias182
Matthias182 26.04.2022 um 09:45:14 Uhr
Goto Top
Ich habe hier nur die Windows Firewall und die ist im Moment deaktiviert. Interessant finde ich, dass Putty und OpenSSH die gleiche Meldung liefern. Putty ist doch eigentlich ein eigener SSH Client, oder? Also liegt wieder der Verdacht nahe, dass es auch außerhalb des Clients liegt (liegen könnte).
Mitglied: lcer00
lcer00 26.04.2022 um 09:51:50 Uhr
Goto Top
Hallo,
Zitat von @Matthias182:

Ich habe hier nur die Windows Firewall und die ist im Moment deaktiviert. Interessant finde ich, dass Putty und OpenSSH die gleiche Meldung liefern.
nö. das sagt nur, dass entweder Putty oder Openssh oder beide nicht kaputt sind.
Putty ist doch eigentlich ein eigener SSH Client, oder? Also liegt wieder der Verdacht nahe, dass es auch außerhalb des Clients liegt (liegen könnte).
Nein, dann müßtest Du auf dem Wireshark-Trace ausgehende SSH-Pakete sehen, die wegen Problemen außerhalb des Clients unbeantwortet bleiben.

Arbeit bitte die Punkte oben ab. Und vielleicht postest Du noch einen Screenshot vom Startbildschirm Wireshark, bevor Du das Interface auswählst (also die Interfaceliste).

Grüße

lcer
Mitglied: Matthias182
Matthias182 26.04.2022 um 09:54:28 Uhr
Goto Top
Also habe jetzt die Ports am Switch getauscht. Ergebnis ist das gleiche.

Hier der Screenshot aus Wireshark

2022-04-26 09_53_46-die wireshark netzwerk analysesoftware
Mitglied: lcer00
lcer00 26.04.2022 um 10:09:37 Uhr
Goto Top
Zitat von @Matthias182:

Also habe jetzt die Ports am Switch getauscht. Ergebnis ist das gleiche.

Hier der Screenshot aus Wireshark
na was sind das denn für 2 LAN verbindungen? Bitte die Ausgabe von IPConfig /all

Grüße

lcer
Mitglied: Matthias182
Matthias182 26.04.2022 um 10:14:02 Uhr
Goto Top
Das ist ein VPN. Das deaktiviere ich aber zum Testen immer. Außerdem habe ich auch das schon mitgelesen und auch dort kommt kein SSH an.
Mitglied: lcer00
lcer00 26.04.2022 um 10:22:13 Uhr
Goto Top
Zitat von @Matthias182:

Das ist ein VPN. Das deaktiviere ich aber zum Testen immer. Außerdem habe ich auch das schon mitgelesen und auch dort kommt kein SSH an.

Sorry, aber das ist falsch. Da werden 2 Schnittstellen mit Traffic angezeigt: Ethernet2 und Ethernet3. Die sind also beide aktiv. Wo ist das Problem mit der Ausgabe von ipconfig /all ?

Und hast Du an der Netzwerkkarte VLAN-IDs eingetellt?

Grüße

lcer
Mitglied: Matthias182
Matthias182 26.04.2022 um 10:24:46 Uhr
Goto Top
Gar nicht, wollte es nur erklären.

Mitglied: lcer00
lcer00 26.04.2022 um 10:32:01 Uhr
Goto Top
Hallo,

OK, Hast Du Software von zscaler drauf installiert?

Grüße

lcer
Mitglied: Matthias182
Matthias182 26.04.2022 um 10:32:53 Uhr
Goto Top
ja, richtig.
Mitglied: lcer00
Lösung lcer00 26.04.2022 um 10:39:56 Uhr
Goto Top
Zitat von @Matthias182:

ja, richtig.

Na dann würde ich erst mal sicherstellen, das diese Sicherheitssoftware ausgehenden SSH-Verkehr auch zulässt. Dein Problem liegt irgendwo zwischen Putty und Netzwerkadapter.

Grüße

lcer
Mitglied: Matthias182
Matthias182 26.04.2022 um 10:41:34 Uhr
Goto Top
Das verstehe ich generell, wenn ich die ZScaler aber beim testen deaktiviere (nicht nur die Verbindung kappe), dann sollte das keinen Einfluss haben.
Mitglied: lcer00
lcer00 26.04.2022 um 10:42:50 Uhr
Goto Top
Zitat von @Matthias182:

Das verstehe ich generell, wenn ich die ZScaler aber beim testen deaktiviere (nicht nur die Verbindung kappe), dann sollte das keinen Einfluss haben.

Dein Wireshark-Trace zeigt aber Traffic auf diesem Interface an (die kleinen Graphen neben dem Interfacenamen)! also ist da nix deaktiviert.

Grüße

lcer
Mitglied: Matthias182
Matthias182 26.04.2022 um 10:45:56 Uhr
Goto Top
Ich habe es jetzt natürlich wieder aktiv gehabt, als ich den Screenshot gemacht habe.
Mitglied: Reini82
Reini82 26.04.2022 um 11:54:47 Uhr
Goto Top
Zitat von @Matthias182:

Ich habe es jetzt natürlich wieder aktiv gehabt, als ich den Screenshot gemacht habe.

Evtl. aber doch mal die Log Dateien von ZScaler anschauen. Wenn er die Verbindung untersagt, dann sollte auch eine Meldung ausgegeben werden.
Mitglied: lcer00
lcer00 26.04.2022 um 12:13:20 Uhr
Goto Top
Hallo,
Zitat von @Matthias182:

Ich habe es jetzt natürlich wieder aktiv gehabt, als ich den Screenshot gemacht habe.
Bitte mach mal folgendes:

  • VPN deaktivieren
  • Wireshark starten, Screenshot von den Interfaces hier posten
  • das Interface auswählen, auf dem Traffic sichtbar ist (drüfte dann nur 1 sein) und den Trace starten
  • als Filter "tcp.dstport == 22" angeben
  • ssh starten
  • Screenshot vom Wireshark-Trace posten

Außerdem bitte mal folgendes im Powershell:

oder Etnerhet3, je nachdem welcher Adapter nicht das VPN ist

Grüße

lcer
Mitglied: Matthias182
Matthias182 27.04.2022 um 06:39:23 Uhr
Goto Top
Durch die ZScaler Logs bin ich gestern mal durch. Das ist eine Arbeit. Ich konnte aber nichts finden, was auf SSH hindeutet.

Jetzt zum Testen ist er auch wieder deaktiviert. Hier das Bild aus Wireshark dazu:
2022-04-27 06_33_41-die wireshark netzwerk analysesoftware

Habe dann den Test wiederholt und auch den Befehl in der Powershell so abgesetzt. HIer aus Output:

Und der Mitschnitt in Wireshark ist leer mit dem Filter auf den Port:
2022-04-27 06_39_06-_ethernet 3
Mitglied: lcer00
Lösung lcer00 27.04.2022 um 08:58:14 Uhr
Goto Top
Hallo,

Habe dann den Test wiederholt und auch den Befehl in der Powershell so abgesetzt. HIer aus Output:
OK, also da sind neben den Microsoft-Treibern NPCAP (Wireshark und oder andere) sowie der "Juniper Network Service". Da würde ich als nächstes schauen, ob der stört.

Und der Mitschnitt in Wireshark ist leer mit dem Filter auf den Port:
Das heisst nunmal, dass der Client nix generiert.

Zur Sicherheit kannst Du das mit https://docs.microsoft.com/en-us/sysinternals/downloads/tcpview überprüfen:

Runterladen, starten und als Filter ssh eingeben.
Dann per Windows ssh die Verbindung starten. Wenn es versucht zu verbinden, dann erscheint ein grüner Eintrag von ssh.exe, der bei Timeout rot wird.
ssh2

Grüße

lcer
Mitglied: Matthias182
Matthias182 27.04.2022 um 12:36:24 Uhr
Goto Top
Also die Tests hatte ich immer parallel mit mehreren Tools gemacht, also OpenSSH, Puttyx und auch meinen DB Client.

Was macht denn jetzt TCPView anders? Ist das nicht das gleiche in grün wie Wireshark? Erwartest du da andere Ergebnisse?
Mitglied: lcer00
lcer00 27.04.2022 um 12:58:58 Uhr
Goto Top
Hallo,
Zitat von @Matthias182:

Also die Tests hatte ich immer parallel mit mehreren Tools gemacht, also OpenSSH, Puttyx und auch meinen DB Client.
Du Testers damit aber eigentlich immer das selbe.
Was macht denn jetzt TCPView anders? Ist das nicht das gleiche in grün wie Wireshark?
Wireshark nutzt den PCAP-Treiber im Netzwerkstack. Tcpview nicht.
Erwartest du da andere Ergebnisse?
Hast Du andere Vorschläge?

Grüße

lcer
Mitglied: aqui
aqui 27.04.2022 um 17:31:56 Uhr
Goto Top
So oder so ähnlich sollte das auf dem Wireshark aussehen:
ssh
Mitglied: commodity
Lösung commodity 29.04.2022 um 11:50:02 Uhr
Goto Top
Hallo,
in der Tat ein schräges Problem. Ideal für einen Freitag. :-) face-smile
Also: Firewall des Servers und LAN scheiden ja aus. Zum einen hat der andere Client Zugriff, zum anderen gibt Putty ja eine Meldung nach Connect aus. Wenn es überhaupt keinen Connect gäbe, gäbe es in Putty einen Timeout. Da im Server-Log aber nichts steht, geht der Connect wohl irgendwo anders hin.

Firewall des Clients scheidet auch aus, auch dann gäbe Putty keine Rückmeldung. Außerdem könntest Du das mit einem simplen telnet <server> 22 klären. Vor allem aber hast Du sie ja zwischenzeitlich deaktiviert.

Irritierend ist natürlich, dass der Wireshark nichts anzeigt - aber das bringt uns ja zugleich auch auf die Spur:
Wenn tatsächlich Connect erfolgt, Wireshark aber nichts anzeigt, läuft der Verkehr wohl über eine andere Connection. Da war Kollege Icer ja schon auf der heißen Spur - Zscaler. Du schreibst, das ist ein VPN(-Dienst?).

Für die Meldungskombi wirft Google u.a. diesen Link aus:
https://www.reddit.com/r/techsupport/comments/ad9rz8/ssh_network_error_p ...

dessen Ergebnis ...
I have NordVPN installed and use it regularly, there is a feature called "Invisibility on LAN". This was blocking local traffic (I couldn't get to my router config page using the web browser.). It seems that even when you're not connected to the VPN and the VPN application is closed it (even if you sign out and then close it) will still block this traffic.
... schon zu dem merkwürdigen Fehlerbild passt:
a) Client 1 kommt nicht durch, Client 2 schon
b) Putty bekommt eine Verbindung zum Server, der Traffic wird aber nicht zugelassen
c) Wireshark zeigt nichts an (wahrscheinlich die VPN-Dienstsoftware den Verkehr abfängt und auf ein anderes Interface legt)

Wenn Du jetzt noch hoffentlich bestätigst, dass der andere PC diesen VPN-Dienst nicht hat, dann sind wir vielleicht auf der richtigen Spur. ;-) face-wink

Viele Grüße, commodity
Mitglied: lcer00
lcer00 29.04.2022 um 12:07:41 Uhr
Goto Top
Hallo,

Wireshark zeigt nichts an (wahrscheinlich die VPN-Dienstsoftware den Verkehr abfängt und auf ein anderes Interface legt)

Genau deshalb wäre mein Tipp, mal tcpview zum Test zu verwenden.

Und wie oben zu sehen, hat der TO außer Wireshark noch 2 weitere DrittanbieterTreiber im Netzwerkstack gebunden.

Grüße

lcer
Mitglied: aqui
aqui 29.04.2022 aktualisiert um 16:42:39 Uhr
Goto Top
Wireshark aber nichts anzeigt, läuft der Verkehr wohl über eine andere Connection.
Ein simples route print hätte uns dann alle erleuchtet! ;-) face-wink
Fazit:
  • Doppelte IP im Netz
  • TCP 22 Traffic geht über ein anderes Gateway der anderen Interfaces ins Nirwana
  • IPv6 aktiv und es wird primär die IPv6 Verbindung verwendet eines anderen Interfaces
Eins von den Dreien wirds wohl sein.
Mitglied: Reini82
Reini82 01.05.2022 um 12:32:02 Uhr
Goto Top
Alternativ mal ZScaler laufen lassen, mit Wireshark das Interface anschauen ob der von @aqui beschriebene Traffic zum ZScaler geht. Wenn ja die Log Dateien und Einstellungen am ZScaler nochmals anschauen.
Mitglied: Matthias182
Matthias182 02.05.2022 um 07:02:05 Uhr
Goto Top
Hallo zusammen,

hatte leider die letzten Tage etwas wenig Zeit, um mich hier zu kümmern. Vielen Dank für die weitere Unterstützung. Ich versuche mal alle Hinweise zu beantworten:

1. tcpview habe ich probiert. Tue mich mit dem Tool noch etwas schwer, aber ich finde dort keinen Hinweis auf Putty oder meine DB Gui. Wonach suche ich denn genau?

2. Der Hinweis mit NordVPN ist spannend. Der zweite PC hat kein ZScaler installiert. Was mich dann aber wundert, Zugriffe über den Browser sind in meinem Fall möglich

3. Der print route zeigt zu meiner Verwunderung kaum Adressen aus meinem internen Netz an (192.xxx.xxx.xxx), lediglich meine eigene vom Rechner und den Router. Die Zieladdresse aus Putty taucht dort nicht auf. Sehr interessant ist aber, dass fast alle Verbindungen über ein mir unbekanntes Gateway geroutet werden. Dabei fä#llt auf, dass die IP Adresse dieses Interface sehr der (virtuellen) IP vom ZScaler aussieht. Eine doppelte IP erscheint mir merkwürdig, ich nutze nur DHCP und setze dort Adressen als fest zugewiesen, nach Bedarf.

4. IPv6, wo müsste ich das suchen?

5. Ich habe mal Wireshark auf das Interface vom Zscaler gehängt. Da finde ich dann aber trotzdem auch keinen SSH Traffic und auch die im Putty verwendete IP Adresse Adresse für das Verbindungsziel taucht dort nicht auf.
Mitglied: lcer00
lcer00 02.05.2022 um 07:11:01 Uhr
Goto Top
Hallo,

OK, damit man weiterkommt: Poste doch mal die konkrete Ausgabe von:

Und nimm tcpview in der Kombi mit ssh aus der Windows-Kommandozeile - so wie oben beschrieben.

Grüße

lcer
Mitglied: Matthias182
Matthias182 02.05.2022 um 07:32:40 Uhr
Goto Top
Also bei mir taucht im tcpview dieser Eintrag nicht auf:

2022-05-02 07_32_18-tcpview - sysinternals_ www.sysinternals.com
Mitglied: colinardo
Lösung colinardo 02.05.2022 aktualisiert um 08:13:36 Uhr
Goto Top
Servus,
das sieht mir nach dieser Policy aus, da ja offensichtlich schon SSH Verbindungen gefiltert werden bevor sie die NIC überhaupt verlassen.

356f009bc871d66dc13280b4c1bf6c8457b59e51__01

Denn das "Operation not permitted" im SSH der Konsole kommt schon direkt vom OS und verbietet wohl die Nutzung des Ports komplett.

Ich hätte den Cloud-Tunnel-Krams am besten schon von Anfang an komplett runter geschmissen (nicht nur deaktiviert!), diese Clients verbiegen oftmals nicht gerade wenig im Netzwerkstack und Filter die dann im schlimmsten Fall wie hier auch noch aktiv sind wenn die Software es nicht ist.

Grüße Uwe
Mitglied: commodity
Lösung commodity 02.05.2022 aktualisiert um 08:34:33 Uhr
Goto Top
Zitat von @Matthias182:
Der zweite PC hat kein ZScaler installiert.
... dass fast alle Verbindungen über ein mir unbekanntes Gateway geroutet werden. Dabei fä#llt auf, dass die IP Adresse dieses Interface sehr der (virtuellen) IP vom ZScaler aussieht.
Dachte ich's mir doch. Dann haben wir eine klare Verdachtsrichtung.
5. Ich habe mal Wireshark auf das Interface vom Zscaler gehängt. Da finde ich dann aber trotzdem auch keinen SSH Traffic und auch die im Putty verwendete IP Adresse Adresse für das Verbindungsziel taucht dort nicht auf.
Wenn, musst Du sicher das neu entdeckte "unbekannte" Interface nehmen. Ich würde an dieser Stelle aber gar nicht noch groß forschen, sondern den Rat des Kollegen @colinardo aufgreifen:
Ich hätte den Cloud-Tunnel-Krams am besten schon von Anfang an komplett runter geschmissen

Viele Grüße, commodity

Edit: Hier gibt's noch etwas Futter zum Thema: https://community.zscaler.com/t/ztunnel-2-0-interception-of-non-http-por ...
Mitglied: Matthias182
Matthias182 02.05.2022 um 08:54:08 Uhr
Goto Top
Ja, das ist genau der Grund gewesen. Das Setting im ZScaler scheint den Verkehr dahingehend umzuleiten. Es kommt dann tatsächlich nichts mehr am NIC an, außer eben HTTP/HTTPS.

Ich schaue jetzt mal, ob ich da Ausnahmen definieren kann, weil SSH im internen Netz sollte schon möglich sein.
Mitglied: commodity
commodity 02.05.2022, aktualisiert am 05.05.2022 um 23:31:32 Uhr
Goto Top
Hand aufs Herz: Alle in diesem Thread haben zur Lösung beigetragen, oder? Besonders engagiert der Kollege @icer00. Da wären ein paar weitere Mausklicks auf "Zur Lösung beigetragen" vielleicht noch drin...
Ist auch motivationsfördernd ;-) face-wink

Wie kann ich einen Beitrag auf "gelöst" oder "erledigt" setzen?

Zusätzlich sollte der Fragesteller die Antworten welche zur Lösungsfindung beigetragen haben, durch einen Klick auf "Zur Lösung beigetragen" neben der jeweiligen Antwort, markieren.//

Viele Grüße, commodity
Mitglied: lcer00
lcer00 02.05.2022 um 10:06:09 Uhr
Goto Top
Hallo,
Zitat von @commodity:
5. Ich habe mal Wireshark auf das Interface vom Zscaler gehängt. Da finde ich dann aber trotzdem auch keinen SSH Traffic und auch die im Putty verwendete IP Adresse Adresse für das Verbindungsziel taucht dort nicht auf.
Wenn, musst Du sicher das neu entdeckte "unbekannte" Interface nehmen.
Das glaube ich nicht. Wenn man "ssh operation not permitted" googled findet man etliche Hinweise in Richtung Installation, Dateizugriffsrechte etc.

Auch der Test mit TCPView zeigt ja nichts - auch kein erfolgloses Verbinden. Ich denke, hier wird erst gar nicht eine TCP-Verbidnung aufgebaut sondern der Wunsch eines Verbindungsaufbaus wird direkt unterbunden. Daher sind Wireshark (Paketanalyse nach Interfaceauswahl) und TCPView (Verbindungszustandsanalyse egal welches Interface) hier erfolglos.

Aber egal. Sicherheitssoftware macht das Leben vielleicht sicherer, aber eben nicht einfacher.

Grüße

lcer
Mitglied: Matthias182
Matthias182 02.05.2022 um 10:14:02 Uhr
Goto Top
Das mache ich doch gerne. Ich dachte es geht darum, die inhaltliche richtige Lösung zu markieren, damit das später schnell gefunden werden kann.
Mitglied: commodity
commodity 02.05.2022 um 11:11:46 Uhr
Goto Top
Zitat von @Matthias182:
Das mache ich doch gerne.
Prima :-) face-smile und Danke!
Es geht natürlich um die Lösung, aber auch ums "Beitragen". Das geschieht ja hier ganz oft im Kollektiv. Schon Icer hatte den ersten Gedanken in die Richtung. Ich habe die Feststellungen dann zusammen gefasst, konkretisiert und mit dem passenden Link versehen, aqui hat es als wahrscheinlich bestätigt und Colinardo das richtige Bild gefunden. So läuft es oft in der IT. Ein Einzelner braucht ewig, wo mehrere unterschiedliche Perspektiven den Weg schnell ebnen.

In meinem Falle war es wohl konkret (der nicht markierte) Beitrag 29.04.2022 um 11:50:02 Uhr, der dem Thread die Zielrichtung gegeben hat. Der wäre also als grün zu empfehlen gewesen. Aber passt schon ;-) face-wink

Viele Grüße, commodity
Mitglied: colinardo
Lösung colinardo 02.05.2022 aktualisiert um 11:32:16 Uhr
Goto Top
Zitat von @commodity:
und Colinardo das richtige Bild gefunden.
Nicht gefunden, hatte diesen Krampf mal selbst auf eine meiner Test-VMs geklatscht und dass ganze nachvollzogen ... War also schon etwas mehr Aufwand dahinter als nur Google zu quälen bis es raucht ...
Mitglied: commodity
commodity 02.05.2022 um 11:59:42 Uhr
Goto Top
diesen Krampf mal selbst auf eine meiner Test-VMs geklatscht ...
Respekt! Da kann man mal wieder sehen, was sich hier einige Kollegen für Mühe geben!

Viele Grüße, commodity