KVM over IP Lösung für Single Host mit PS/2?

Zitat von GrandAdmiralThrawn

PS/2 Keyboard + PS/2 Maus + VGA

Das ist wohl der Knackpunkt für eine halbwegs "moderne" Lösung.

Hast dir den schon mal angesehen? http://www.raritan.com/eu/de/produc...inion-kx-ii-101

Kenn das Produkt nicht, aber der Firma ist aufgrund ihrer Enterprise Lösungen zumindest ein gutes Produkt zuzutrauen. Preis ist leicht über deinem angestrebten Limit.

Remote Desktop/SSH ist keine Lösung?

In der Zwischenzeit habe ich Mal den Java Client von Trendnet dekompiliert. Der Blocker Bug passiert beim SSL Handshake wenn man ein Clientzert und eine zu neue JRE verwendet. Das sollte sich doch fixen lassen. Ich brings wohl selbst ned zusammen. Hab zwar die sonstigen Fehler beseitigen können die bei JDK 1.7 auftreten und erfolgreich einen 1.7er Build rausgelassen, aber den SSL Bug wird wohl ein echter Java Coder fixen müssen.

Ein Debug Run hat auch ned so viel aufschlußreiches ergeben, außer daß er scheinbar einen SSL Cipher im Kontext eines TLSv1 Protokolls verwenden will. Mal eine funktionierende Version mit JDK 1.6u21 bauen und schaun wie das da ausschaut..

Und wenn das alles kapital failed is, dann wohl Raritan?

is jetzt ned so meine materie muss ich gestehen, aber avocent hat nichts passendes im sortiment für dich? mir ist der hersteller nur im hinterkopf geblieben bezgl. kvm-lösungen, ist mal als hersteller bei einer unserer distis als lösungsanbieter in erscheinung getreten..

Ja, für'n IBM. Die RSA gibts scheinbar für Netfinities und eServer sowie xSeries, der PC Server 704 ist nicht extra gelistet. Zudem sind alle PCI Slots voll. Das ließe sich zwar regeln durch Wechsel auf eine 2-Port NIC, aber najo, extern is mir lieber, richtig out-of-band.

Avocent hätte schon passendes, aber deren kleinste Lösung - der Avocent AutoView 1415 - ist schon viel zu fett und teuer.

Ich werd mich mit 1-2 sehr fähen Java Devs zusammensetzen und schaun ob sich der dekompilierte Client von Trendnet nicht fixen läßt. Ein paar schirche Sachen im Code konnte ich schon beheben, womit sich das Teil jetzt mit JDK 1.7 und 1.8 in Eclipse Luna bauen und ausführen läßt.

Nur der Bug im SSL Handshake bei PKI Auth gehört fixed/umschifft/whatever. Wenn das gelingt, behalte ich den Schrott. Wenn nicht, dann ist Raritan wohl die nächste Anlaufstelle so wie es aktuell aussieht (das war schon Mal sicher kein so mieser Vorschlag, nur die lokale PS/2 Konsole geht mir ab).

Ich war immer mit dem Nick hier, ja. Ich bin aber seit vielen Jahren kaum noch aktiv, hier und da post ich halt Mal. Daher kanns gut sein, daß ich unter deinem Radar durch bin. Die Zeit als ich noch sehr aktiv war, das war so zu Tualatin Pentium III-S und Pentium 4 Zeiten.

Aber egal!

Ich habe den Trendnet Java Viewer gefixt!

Das war vielleicht was, noch dazu für mich mit NULL Plan in Java. Also: Mit Java 1.6u29 hat Oracle offensichtlich einen Fix zum Blocken von BEAST eingebaut. Dieser Fix blockt die Renegotiation bei Verwendung unsicher implementierter verketteter Blockcipher (CBC).

Super, da der KVM nur einen EINZIGEN Cipher beherrscht: SSL_RSA_WITH_3DES_EDE_CBC_SHA. Ein CBC. Ein ziemlicher Schundcipher noch dazu.

Schritte:

• JAR/class File(s) mittels [Java Decompiler] dekompilieren.
• Java Files in ein Eclipse Luna Projekt importieren.
• Haufen Code Errors bzw. Java7 Requirements fixen.
• SSL Bug "fixen" (ganz so kann/darf man das nicht ausdrücken).
• Kompilieren & in ein JAR packen.
• Profit!

Also die Main Klasse aufgemacht, und ganz vorne folgenden Code eingepflegt, der nicht nur für die Zukunft das interoperable/insecure Handshaking fix festlegt, sondern auch die CBC Protection wieder deaktiviert:

Code:

java.lang.System.setProperty("jsse.enableCBCProtection", "false");
java.lang.System.setProperty("sun.security.ssl.allowUnsafeRenegotiation", "false");
java.lang.System.setProperty("sun.security.ssl.allowLegacyHelloMessages", "true");

Links dazu:

• [CBC/BEAST Fix]
• [Renegotiation Issue]

Super ist halt, daß ich damit BEAST vulnerable bin, aber wenn der Switch halt sonst nichts kann. Man kann noch ned Mal auf einen Stream Cipher wie RC4 umsteigen, echt arm. Aber najo.

Immer noch besser als JRE 1.6u27 installieren, mein Code baut und läuft wenigstens mit Java 7u60 und 8u5. Zudem über 10 Errors und 60 Warnings im Code eliminiert, alles sauber jetzt.

Genug Java für die nächsten Jahre!

Den Code und das JAR an Trendnet geschickt, attached an mein Supportticket. Mal gespannt was die sagen, entweder freuen sie sich, oder verklagen mich fürs Dekompilieren ihres Viewers.

So, Server rebooted für einen echten Test (der Maus-PS/2 war nicht aktiv, vergessen beim letzten Boot anzuschließen).

Wenn man bedenkt, daß ich wie eine Wildsau grunzend durch den Code gewütet habe - des öfteren nicht so genau wissend WAS ich da gerade tue - ist es echt verwunderlich, wie sauber das jetzt rennt...

Eh gut, ich bin nämlich viel zu faul, das *******teil zur Post zu bringen. Code häckn kann man wenigstens gemütlich im Sessel, muß ich ned aufstehn.

Klar, aber ich hatte den Code ohnehin schon dekompiliert, also hab ich ihn gleich fixed, damit er als JDK 1.7 Projekt gebaut werden kann. Und dabei war es naheliegend, die Property mit in den Code einzubringen, damit man das eben nicht auf der Kommandozeile angeben muß (hatte ich zwischenzeitlich zum Testen natürlich schon auch so gemacht).