79
Zugriff auf Clients im gleichen Netz nicht möglich
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
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2591406421
Url: https://administrator.de/contentid/2591406421
Ausgedruckt am: 25.11.2024 um 14:11 Uhr
79 Kommentare
Neuester Kommentar
Hallom
Grüße
lcer
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?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.
Grüße
lcer
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).
Hallo,
Wie verbindest Du Dich? per Password oder per Zertifikat?
Grüße
lcer
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.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).
Wie verbindest Du Dich? per Password oder per Zertifikat?
Grüße
lcer
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
Bist du sicher? Ich nutze ja auch parallel dieses DB GUI Tool (HeidiSQL) und das nutzt doch kein SSH für die Verbindung, oder?
Hallo,
doch, macht es: https://www.heidisql.com/help.php#connecting
Grüße
lcer
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?
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
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 !
Zum Rest hat Kollege @lcer00 oben schon alles gesagt.
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?
Ping wird ausgeführt für 192.168.10.115 mit 32 Bytes Daten:
Antwort von 192.168.10.115: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.10.115: Bytes=32 Zeit=2ms TTL=64
Antwort von 192.168.10.115: Bytes=32 Zeit=2ms TTL=64
Antwort von 192.168.10.115: Bytes=32 Zeit=2ms TTL=64
Ping-Statistik für 192.168.10.115:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 1ms, Maximum = 2ms, Mittelwert = 1msUnd TRACERT liefert:
Routenverfolgung zu 192.168.10.115 über maximal 30 Hops
1 1 ms 1 ms 1 ms 192.168.10.115
Ablaufverfolgung beendet.Da fällt mit auf, dass der Weg direkt zum Server geht, ohne Standard-Gateway dazwischen. Ist das richtig im Selben VLAN?
Wenn ich dann in die log.auth schaue finde ich zu SSH dort nur:
Hallo,
Verbindest Du Dich auch auf Port 22?
Grüße
lcer
Verbindest Du Dich auch auf Port 22?
Grüße
lcer
Ja, natürlich 
Na dann zeig mal die Ausgabe von ssh in der Kommandozeile:
ssh 192.168.10.115 -l benutzernameAch ja, was für ein Switch ist das?
Grüße
lcer
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
ssh: connect to host 192.168.10.115 port 22: Permission denied
Der Switch ist ein Cisco SG200-26P
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?
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
Hallo,
dann poste mal vom Server die /etc/ssh/sshd_config
Und was ist mit den ssh-Versionen?
Grüße
lcer
dann poste mal vom Server die /etc/ssh/sshd_config
Und was ist mit den ssh-Versionen?
Grüße
lcer
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
zu den Versionen:
SHA-1 wurde 2021 zur Verwendung mit SSH deaktiviert.
This release disables RSA signatures using the SHA-1 hash algorithm
by default. This change has been made as the SHA-1 hash algorithm is
cryptographically broken, and it is possible to create chosen-prefix
hash collisions for <USD$50K [1]damit passt, sind folgende Versionen erforderlich:
Putty >= 0.75
und OpenSSH >= 8.8
Grüße
lcer
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):
Und hier der Auszug aus der Config:
SSH Versionen:
Windows(Client): OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2
Linux(Server):
Und hier der Auszug aus der Config:
Putty habe ich Version 0.76
Schau sonst nochmal Protokolldateien auf dem Server an.
Grüße
lcer
Ich verwende zum Testen im Moment root.
Aber meint PermitRootLogin = yes nicht genau das Gegenteil, also ich kann mich mit root anmelden?
Aber meint PermitRootLogin = yes nicht genau das Gegenteil, also ich kann mich mit root anmelden?
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.
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.
Handbuch lesen hilft hier, wie immer.
sudo iptables -L -v -n
sudo nft list tables
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.
Gibt es noch andere Firewalls?
Solltest du als Linux Profi eigentlich wissen !! 🧐 iptables und nftablessudo iptables -L -v -n
sudo nft list tables
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.
iptables liefern nur eine leere Liste, nftables gibt es nicht.
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.)
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.)
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.
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
https://phoenixnap.com/kb/ssh-permission-denied-publickey
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?
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.....
Also tcpdump erkennt auf dem Port 22 keinen Datenverkehr. Habe sowohl Putty als auch openSSH probiert.
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...
Du musst also herausfinden warum der Client gar keinen SSH Traffic sendet. Gateway Fehler, Lokale Firewall, Router ACL, usw.
Du musst also herausfinden warum der Client gar keinen SSH Traffic sendet. Gateway Fehler, Lokale Firewall, Router ACL, usw.
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?
Gateway Fehler, Lokale Firewall, Router ACL, usw.
Geprüft?
Geprüft?
1
Hallo,
Poste mal die Ausgabe von > tracert 192.168.10.115
Grüße
lcer
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?
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
Der Traceroute ist leider sehr schmal:
Routenverfolgung zu 192.168.10.115 über maximal 30 Hops
1 1 ms 1 ms 1 ms 192.168.10.115
Ablaufverfolgung beendet.
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:
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... 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?"
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?
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?
Hallo,
Sind das die Wireshark-Traces vom Client oder vom Server?
Grüße
lcer
Zitat von @aqui:
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?"
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... 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
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.
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.
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.
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:
Grüße
lcer
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
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ß
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ß
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 @90948 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.
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 @90948 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.
Hallo,
Grüße
lcer
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.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.
Grüße
lcer
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).
Hallo,
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
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.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).
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
Also habe jetzt die Ports am Switch getauscht. Ergebnis ist das gleiche.
Hier der Screenshot aus Wireshark
Hier der Screenshot aus Wireshark
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 /allAlso habe jetzt die Ports am Switch getauscht. Ergebnis ist das gleiche.
Hier der Screenshot aus Wireshark
Grüße
lcer
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.
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.
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
Gar nicht, wollte es nur erklären.
Ethernet-Adapter Ethernet 2:
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Zscaler Network Adapter 1.0.2.0
Physische Adresse . . . . . . . . : 00-FF-AF-FD-E8-33
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
IPv4-Adresse . . . . . . . . . . : 100.64.0.2(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.0.0
Standardgateway . . . . . . . . . :
DNS-Server . . . . . . . . . . . : 100.64.0.3
100.64.0.4
100.64.0.5
NetBIOS über TCP/IP . . . . . . . : Aktiviert
Ethernet-Adapter Ethernet:
Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Intel(R) Ethernet Connection (10) I219-LM
Physische Adresse . . . . . . . . : 8C-8C-AA-00-4E-0A
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
Ethernet-Adapter Ethernet 3:
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Lenovo USB Ethernet
Physische Adresse . . . . . . . . : 48-2A-E3-9E-C5-6B
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
IPv4-Adresse . . . . . . . . . . : 192.168.10.125(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Lease erhalten. . . . . . . . . . : Dienstag, 26. April 2022 09:10:13
Lease läuft ab. . . . . . . . . . : Dienstag, 26. April 2022 10:32:09
Standardgateway . . . . . . . . . : 192.168.10.1
DHCP-Server . . . . . . . . . . . : 192.168.10.1
DNS-Server . . . . . . . . . . . : 192.168.10.1
NetBIOS über TCP/IP . . . . . . . : Aktiviert
Ethernet-Adapter Bluetooth-Netzwerkverbindung:
Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Bluetooth Device (Personal Area Network)
Physische Adresse . . . . . . . . : B0-A4-60-14-85-D8
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
Hallo,
OK, Hast Du Software von zscaler drauf installiert?
Grüße
lcer
OK, Hast Du Software von zscaler drauf installiert?
Grüße
lcer
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
Das verstehe ich generell, wenn ich die ZScaler aber beim testen deaktiviere (nicht nur die Verbindung kappe), dann sollte das keinen Einfluss haben.
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.
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
Ich habe es jetzt natürlich wieder aktiv gehabt, als ich den Screenshot gemacht habe.
Zitat von @Matthias182:
Ich habe es jetzt natürlich wieder aktiv gehabt, als ich den Screenshot gemacht habe.
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.
Hallo,
Außerdem bitte mal folgendes im Powershell:
oder Etnerhet3, je nachdem welcher Adapter nicht das VPN ist
Grüße
lcer
Zitat von @Matthias182:
Ich habe es jetzt natürlich wieder aktiv gehabt, als ich den Screenshot gemacht habe.
Bitte mach mal folgendes:Ich habe es jetzt natürlich wieder aktiv gehabt, als ich den Screenshot gemacht habe.
- 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:
get-netadapterbinding -Name "Ethernet2" Grüße
lcer
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:
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:
Jetzt zum Testen ist er auch wieder deaktiviert. Hier das Bild aus Wireshark dazu:
Habe dann den Test wiederholt und auch den Befehl in der Powershell so abgesetzt. HIer aus Output:
get-netadapterbinding -Name "Ethernet 3"
Name DisplayName ComponentID Enabled
---- ----------- ----------- -------
Ethernet 3 QoS-Paketplaner ms_pacer True
Ethernet 3 Client für Microsoft-Netzwerke ms_msclient True
Ethernet 3 Microsoft-LLDP-Treiber ms_lldp True
Ethernet 3 Internetprotokoll, Version 4 (TCP/IPv4) ms_tcpip True
Ethernet 3 Microsoft-Multiplexorprotokoll für Netzwerkadapter ms_implat False
Ethernet 3 Npcap Packet Driver (NPCAP) INSECURE_NPCAP True
Ethernet 3 Datei- und Druckerfreigabe für Microsoft-Netzwerke ms_server True
Ethernet 3 Internetprotokoll, Version 6 (TCP/IPv6) ms_tcpip6 True
Ethernet 3 Antwort für Verbindungsschicht-Topologieerkennung ms_rspndr True
Ethernet 3 E/A-Treiber für Verbindungsschicht-Topologieerk... ms_lltdio True
Ethernet 3 Juniper Network Service jnprns TrueUnd der Mitschnitt in Wireshark ist leer mit dem Filter auf den Port:
Hallo,
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.
Grüße
lcer
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.
Grüße
lcer
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?
Was macht denn jetzt TCPView anders? Ist das nicht das gleiche in grün wie Wireshark? Erwartest du da andere Ergebnisse?
Hallo,
Grüße
lcer
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.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?
Wireshark nutzt den PCAP-Treiber im Netzwerkstack. Tcpview nicht.Erwartest du da andere Ergebnisse?
Hast Du andere Vorschläge?Grüße
lcer
So oder so ähnlich sollte das auf dem Wireshark aussehen:
Hallo,
in der Tat ein schräges Problem. Ideal für einen Freitag.
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 ...
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.
Viele Grüße, commodity
in der Tat ein schräges Problem. Ideal für einen Freitag.
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.
Viele Grüße, commodity
Hallo,
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
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
Wireshark aber nichts anzeigt, läuft der Verkehr wohl über eine andere Connection.
Ein simples route print hätte uns dann alle erleuchtet! 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
1
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.
2
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.
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.
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
OK, damit man weiterkommt: Poste doch mal die konkrete Ausgabe von:
Ipconfig /all
Route printUnd nimm tcpview in der Kombi mit ssh aus der Windows-Kommandozeile - so wie oben beschrieben.
Grüße
lcer
Also bei mir taucht im tcpview dieser Eintrag nicht auf:
Servus,
das sieht mir nach dieser Policy aus, da ja offensichtlich schon SSH Verbindungen gefiltert werden bevor sie die NIC überhaupt verlassen.
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
das sieht mir nach dieser Policy aus, da ja offensichtlich schon SSH Verbindungen gefiltert werden bevor sie die NIC überhaupt verlassen.
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
1Zitat 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.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.
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 ...
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.
Ich schaue jetzt mal, ob ich da Ausnahmen definieren kann, weil SSH im internen Netz sollte schon möglich sein.
Hand aufs Herz: Allein 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
Wie kann ich einen Beitrag als gelöst markieren?
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
Ist auch motivationsfördernd
Wie kann ich einen Beitrag als gelöst markieren?
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
1
Hallo,
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
Zitat von @commodity:
Das glaube ich nicht. Wenn man "ssh operation not permitted" googled findet man etliche Hinweise in Richtung Installation, Dateizugriffsrechte etc.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.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
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.
Prima 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
Viele Grüße, commodity
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
Viele Grüße, commodity
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 ...
3diesen 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
1
