Hallo,

nach längerer Suche finde ich keine Lösung für mein Problem. Und es ist mir auch mittlerweile unerklärlich.

Ich habe ein Monitoring Tool geschrieben, dass alle Cisco Switche im Netzwerk abfragt und mir die gewünschten Werte ausgibt. Das Tool funktioniert super und läuft einwandfrei.

Mein Problem ist; Wir haben jetzt auch zwei Neue Cisco "Small Business" Switches SG350 und auf die beiden habe und bekomme ich mit meinem Tool per SSh (ssh.net im Tool eingebunden) keinen Zugriff.
SSH Zugang wurde am Switch schon aktiviert und eingestellt, sowie ein neuer RSA-Schlüssel erstellt/generiert.
Mit meinem Tool kann ich auf alle Cisco SG300, SG500 und SG550 Switches zugreifen, nur bei den SG350 bekomme ich nicht einmal annährend eine Connection. Wenn ich mit PuTTY auf die SG350 zugreife, funktioniert dies einwandfrei und ohne Verzögerung. Also kann es nicht an den Switches liegen. Denke ich mir mal.

Meine Frage: Hat zu diesem Thema jemand Erfahrung oder stand schon mal vor dem gleichen Problem mit den SG350.....Mir gehen gerade die Ideen aus. Da ich ja mit meinem Tool auf jeden anderen Switch komme.

Schon mal vielen Dank fürs Helfen !!!

Nun, die Wahrscheinlichkeit jemanden zu finden, der genau mit dem Modell genau diese Erfahrungen gemacht hat; da ist es vermutlich einfacher die Nadel im Heuhaufen zu finden.

Hab jetzt in meiner kurzen Zeitlücke einfach mal 10 Sekunden gegoogelt und der erste Treffer war direkt ein Hinweis, dass alte Putty Versionen keine Connection aufbauen können, sondern nur die neuen.
How to Enable SSH Access for Cisco SG350-10P Switches

Ergo scheint hier offenbar etwas am SSH Handshake passiert zu sein, das Du nun nicht mehr abdeckst.

Hallo Abt,

Danke für Deine schnelle Antwort. Auf dieser Seite war ich auch schon und habe danach ssh.net in NuGet aktualisiert, dachte mit dem neuen Update geht es.

Ja, in die Richtung Handshake wird es gehen. Was ich mir auch schon gedacht habe: Ob nicht Cisco eine neue Sicherheitsmaßnahme eingebaut hat....z.B. PuTTY, OpenSSh, etc. dürfen zugreifen (Sie müssen ja einen Weg Freigeben zum Managen der Geräte per Console "CLI") und andere werden Blockiert - nur so eine Vermutung, da es "Nagelneue Geräte sind".

Weil am Handshake der ssh.net Klasse kann ich ja nicht viel machen. Die erforderlichen Parameter sind IP - Switch, Port, Username, Password. Und die anderen Switches verwenden auch alle ssh2, sowie die SG350.

Selbst als ich einmal per PuTTY und einmal per OpenSSH einen Public Key (RSA) generiert und eingepflegt habe, kam ich nicht auf den die SG350 drauf....auf die anderen aber weiterhin ohne Probleme.

Zitat von BlutigerAnfänger2

Ob nicht Cisco eine neue Sicherheitsmaßnahme eingebaut hat....z.B. PuTTY, OpenSSh, etc. dürfen zugreifen (Sie müssen ja einen Weg Freigeben zum Managen der Geräte per Console "CLI") und andere werden Blockiert - nur so eine Vermutung, da es "Nagelneue Geräte sind".

Den Gedanken kannste direkt verwerfen, weil sowas das SSH Protokoll gar nicht zulässt.

Zitat von BlutigerAnfänger2

Weil am Handshake der ssh.net Klasse kann ich ja nicht viel machen.

Warum? Ist doch nur ne Bibliothek - und die ist Open Source. Warum solltest dann nichts machen können?
Davon abgesehen ist die letzte stabile Version 4 Jahre alt; die letzte Beta 3 Monate alt.

Wenn mal nur einen ganz arg kurzen Blick in die Release Notes schaut, dann sind da schon viele Änderungen in der Beta:
Wenn man bedenkt dass Putty 0.67 ebenfalls 2016 released wurde und Putty 0.70 2017; dann sieht das offenbar so aus, dass die stabile Version womöglich die Änderungen, die Putty genossen hat, nicht enthalten hat.

Gibt aber halt keine Garantie oder Verpflichtung, dass das Projekt alle Features von SSH abgedeckt.
Wenn was fehlt, dann füg's hinzu: davon lebt Open Source.

Guckste Dir überhaupt das Zeugs an, das Du extern in Deine Projekte einbindest? ;-)

Stimmt. Muss leider zugeben, das ich die Release Notes nicht gelesen habe. Ist aber ein sehr guter Tipp für die nächsten Male. Ich habe mich nur hier : class/Renci.SshNet/SshClient über die Klasse eingelesen.

Um mein Problem zu lösen, müsste ich jetzt eine aktuellere SSH Klasse finden.

SSH bietet sich idr. nicht zum monitoren von Switchen an. Genau dafür gibt es das Protokoll SNMP.
Wir verwenden hier die Lextm.SharpSnmpLib sehr erfolgreich in der freien Version. Zusammen mit den Python tools "pysmi" unter Linux lassen sich da sehr elegant auch die MIB Files auslesen und die entsprechenden Datenpunkte (Object ID's) bestimmen.


Edit: pysmi eingefügt, sonst machte der Satz keinen Sinn

Danke Papst für den Tipp.

Das ist auch ein guter Rat für ein Projekt von mir. Da SNMP ja bei den OIDs schon recht tricky ist, werde ich das mal prüfen statt für jede SNMP Trap die OIDs in den Manuals nachzulesen :-).

Danke Papst für Deinen Tipp.

Ich habe mir Lextm.SharpSnmpLib angeschaut. Danke nochmal dafür. Werde ich bei meinem nächsten Project das in diese Richtung geht umsetzen.

Bei meinem jetzigen ist es weniger eine "Monitoring" Software -> wir nennen Sie nur so, mehr eine MAC Adressen Abfrage und der Zugriff soll über SSH sein, das ist/war so gefordert.

Dennoch allen nochmal vielen Dank für Euere Hilfe.