SSH auf pfSense intern nicht möglich
-
Moin zusammen,
ich habe mich ja lange nicht mehr zu Wort gemeldet hier. Lange ging alles gut…
Mein jetziges Problem ist, ich komme intern nicht mehr per SSH auf die pfSense. Von draußen allerdings schon.
Die im Anhang angehängte Fehlermeldung bekomme ich von PuTTY Kitty etc... Hat hier jemand einen Ansatz, wo ich suchen kann / muss?
-
Vielleicht einfach eine zu alte Kitty/Putty Version die eine bestimmte Meldung nicht handlen kann? Wie wird denn von außen/innen per SSH zugegriffen? Gleiche Settings etc.?
-
Die Version ist auf meinem lokalen PC die gleiche, wie die auf meinem externen Büro PC.
Intern wird per Name oder IP zugegriffen, geht beides nicht. Extern per DnyDNS auf Name.meineDomain.de. Was intern, immer und egal wie ich es versuche, zur gleichen Meldung führt. -
Wird intern ggf. über die externe IP / DNS zugegriffen? Wird der Zugriff evtl. via NAT/Reflection noch falsch durch die Gegend geroutet?
-
Nicht das ich wüsste, aber auch wenn ich über die interne IP 192.168.1.1 drauf verbinde, kommt die selbe Mendung.
-
Gleicher Fehler hier. Unmittelbar nach dem 2.3.2 Update kein Login mehr mit dem Putty möglich. Eine Stunde zuvor funktionierte das noch.
-
Bei mir geht es schon länger nicht. Hoffte mit dem Update Abhilfe zu schaffen. Leider vergebens.
-
Moin,
gerade ausprobiert putty verbindet, aber erst nachdem ich die beta 0.67 von hier http://www.heise.de/download/product/putty-7016/download benutzt hatte. Release 0.64 mault über den Key exchange algorithm.
-teddy
-
Ich empfehle mal direkt von Simon:
http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
die latest devel snapshots zu nehmen. Im Normalfall sind die lauffähig und haben bspw. schon support für Ed25519 Ciphers mit drin, da hatte ich bislang am wenigsten Probleme mit
-
Moin,
Ich empfehle mal direkt von Simon:
klar, ist die beste Wahl, ich nehme nur gerne Heise als Einstiegsseite weil die Links auf vernünftige Quellen zeigen und ich ich in Windows immer weniger zuhause bin und mir die echten Quellen einfach nicht merken kann, die eine kann ich mir gerade noch so merken ;)
-teddy
-
Die Empfehlung war nur, weils die Snapshots nur bei ihm gibt :)
-
Damit funktionierts. War zuvor mit der Reparatur der pfSense beschäftigt, weil das Update nicht sauber durchlief. Das sind dann wieder solche Momente, die man nicht haben möchte… besonders wenn das Produkt mal in der Firma laufen soll. Testet so ein "volles" Update nur eine Person vor der Freigabe?
-
jimp hatte das anderswo schon einmal beantwortet: es wurden alte, inzwischen nicht mehr als sicher geltende Verschlüsselungsverfahren herausgeworfen, daher die Inkompatibilität mit einigen vorhandenen Einstellungen.
-
Moin,
… Testet so ein "volles" Update nur eine Person vor der Freigabe?
Egal wie viel du testest, alle Kombinationen von Hard-, & Software und Einstellungen geht einfach nicht, leider.
Bei mir sind alle 3 stressfrei durchgelaufen, Glück gehabt.-teddy
-
Dito. Ob APU1 oder eine C2758 Kiste, beide sauber durchgelaufen. Verschiedene Kundensysteme kommen die Tage dran, unsere Testsysteme waren aber auch problemlos. Dafür hatte ich eine Kundenkiste beim letzten Update auf 2.3.1-5, wo sonst alle anderen problemlos waren. Manchmal ist der Teufel eben leider ein Eichhörnchen.
jimp hatte das anderswo schon einmal beantwortet: es wurden alte, inzwischen nicht mehr als sicher geltende Verschlüsselungsverfahren herausgeworfen, daher die Inkompatibilität mit einigen vorhandenen Einstellungen.
OK dann ist die Kitty Fehlermeldung strange, normalerweise sollte sich dann auch über fehlende Cipher oder Key Exchanges beschwehrt werden, das hatten wir schon bei den letzten neuen Ubuntu und Debian Releases. Da fliegen jetzt langsam überall die alten DH Keygruppen und Ciphersuites raus, die unsicher sind.
BTW: Unter Windows - mal abwarten was das Linux unter Windows bringt - ist außer Putty auch MobaXterm einen Tipp wert. Bringt zudem eine lokale cygwin-artige Umgebung mit, mit der lokal unter Windows dann einige Linux Tools zur Verfügung stehen (gerade sachen wie ssh/sftp nativ, rsync etc. sind da praktisch).
-
Sehr wahrscheinlich war zu meiner Updatezeit auch gerade Hochbetrieb auf den Verteilservern. Das dauerte ewig, bis manche Patch-Pakete geladen waren. Durchaus möglich, dass hier irgendwo ein Timeout zugeschlagen hat. Ich sah zwar noch das "successful" irgendwo am Ende im Log. aber nach dem Reboot konnte er aber weder Patch- noch Paketstatus/Version abrufen. Erst der manuelle Update-Aufruf über die Console hat das ganze dann glücklicherweise wieder ins Lot gebracht. Und danach ging der Putty nicht mehr… und ich ins Bett. Aber jetzt ist alles wieder OK. Mal schauen wie sich die beiden neuen Supermicros nachher beim Update anstellen werden.
-
Moin,
meine Updates haben auch eine gefühlte Ewigkeit gedauert, teilweise runter auf 200kbit, ich fühlte mich fast in die alten Mailboxzeiten zurückversetzt: http://computermuseum.htw-berlin.de/index.php/Detail/Object/Show/object_id/229 da war mein Einstieg :'(
-teddy
