Java 1.7 + JSCH: java.security.InvalidKeyException: Der Schlüssel ist zu lang für diesen Algorithmus

9

Ich versuche, JSCH zu verwenden, um eine Datei auf eine entfernte SFTP teilen. Jedes Mal, wenn ich versuche, eine Verbindung mit der Freigabe innerhalb meines Codes herzustellen, erhalte ich eine Ausnahme, die ungefähr so ​​aussieht:

%Vor%

Ich habe Beiträge gesehen, die diesen Fehler beschreiben beim Upgrade auf Java 8, aber wir sind immer noch auf Java 7 und ich weiß nicht genug über die Kryptografie-Unterstützung von Java, um zu wissen, ob das wichtig ist.

Einige Leute schlagen vor, JCE (Java Cryptography Extensions) zu installieren, um dieses Problem zu lösen, also habe ich es versucht, aber ich bekomme immer noch denselben Fehler, nachdem ich die entsprechenden JAR-Dateien in das Verzeichnis / libs / security kopiert und die Anwendung neu gestartet habe. Wir haben bestätigt, dass JCE installiert wurde, indem Sie dieses Skript ausführen und beachten, dass die Ausnahme nicht ausgelöst wurde.

Ich habe auch versucht, mit dem Befehl sftp im ausführlichen Modus eine Verbindung zur Remote-SFTP-Freigabe vom Terminal herzustellen. Folgendes habe ich bekommen:

%Vor%

Wenn ich die Ausgabe richtig lese (und ich kann es nicht sein), hat sich der Handshake-Prozess auf die Verwendung von aes128-cbc für den Schlüsselaustausch und hmac-md5 für die eigentliche Sitzungsverschlüsselung festgelegt. Laut der JSCH-Dokumentation (minimal, obwohl es sein mag), werden beide Algorithmen unterstützt.

Ich kann eine Verbindung zu dieser Freigabe sowohl mit dem Befehlszeilendienstprogramm sftp als auch mit FileZilla herstellen, daher muss das Problem entweder mit JSCH oder mit meiner Java-Konfiguration behoben werden, aber ich weiß nicht, was es ist .

Java Version:

%Vor%

JSCH-Version:

%Vor%

Vielen Dank im Voraus!

BEARBEITEN: Es sieht aus wie ein Fehler für genau dieses Verhalten war eingereicht gegen das JDK, wurde aber ohne Auflösung geschlossen. Es gibt auch einen E-Mail-Thread zwischen den Betreuern von JSCH und den JDK-Entwicklern das bespricht das Problem, hat aber keine Lösung.

    
MusikPolice 18.12.2014, 22:59
quelle

4 Antworten

2

Am Ende haben wir JSCH für SSHJ ausgetauscht. Es hängt von den BouncyCastle Crypto-Bibliotheken ab und nicht von den in Java integrierten Crypto-Paketen und kann problemlos mit unserem Server verbunden werden.

    
MusikPolice 16.01.2015, 20:31
quelle
1

Sie können JSCH zwingen, SHA256 anstelle von SHA1 mit keysize > 1024 (was JSSE nicht mehr zulässt) wie folgt zu verwenden:

%Vor%     
Preben Valeur 28.07.2016 09:33
quelle
0

Tatsächlich wurde der Bug für dieses Verhalten , der gegen das JDK eingereicht wurde, nicht geschlossen - die Entscheidung um es zu schließen wurde es rückgängig gemacht und es wurde ein paar Tage später behoben . Es wurde später zurückportiert, also Upgrade auf Java SE 8u45 (oder höher) löst das Problem ebenfalls.

    
Lukas Pokorny 18.06.2015 20:51
quelle
-1

Installieren Sie Java-Kryptographie-Erweiterung (JCE) Unlimited Strength Jurisdiction Policy-Dateien Klicken Sie auf Hier herunterladen

Ersetzen Sie local_policy.jar und US_export_policy.jar durch folgende nicht eingeschränkte Richtliniendateien: Java \ jre7 \ lib \ Sicherheit \

Ich hatte ein ähnliches Problem während der Verschlüsselung von Daten mit ibm jre Version 1.5 und Tomcat.

    
Kunal Surana 02.01.2015 11:38
quelle

Tags und Links