Próbuję użyć JSCH, aby przesłać plik do zdalnego udziału SFTP. Za każdym razem staram się połączyć z udziałem od wewnątrz mojego kodu, otrzymuję wyjątek, który wygląda mniej więcej tak:Java 1.7 + JSCH: java.security.InvalidKeyException: Klucz jest za długi dla tego algorytmu
com.jcraft.jsch.JSchException: Session.connect: java.security.InvalidKeyException: Key is too long for this algorithm
at com.jcraft.jsch.Session.connect(Session.java:558) ~[jsch-0.1.51.jar:na]
at com.jcraft.jsch.Session.connect(Session.java:183) ~[jsch-0.1.51.jar:na]
widziałem posts that describe this error podczas uaktualniania do Javy 8, ale nadal jesteśmy na Java 7 i nie wiem wystarczająco dużo o obsłudze kryptografii Java, aby wiedzieć, czy to ma znaczenie.
Niektórzy sugerują zainstalowanie JCE (Java Cryptography Extensions), aby rozwiązać ten problem, więc dałem mu szansę, ale nadal mam ten sam błąd po skopiowaniu odpowiednich plików JAR do katalogu/libs/security i ponownym uruchomieniu aplikacji . Potwierdziliśmy, że JCE zostało zainstalowane, wykonując this script i zwracając uwagę, że wyjątek nie został zgłoszony.
Próbowałem również połączyć się ze zdalnym udziałem SFTP z terminala przy użyciu polecenia sftp w trybie szczegółowym. Oto co mam:
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 102: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to XXXXXXXXXXXXX [XXXXXXXXXXXX] port XX.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/Users/XXXXX/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /Users/XXXXX/.ssh/id_rsa type 1
debug1: identity file /Users/XXXXX/.ssh/id_rsa-cert type -1
debug1: identity file /Users/XXXXX/.ssh/id_dsa type -1
debug1: identity file /Users/XXXXX/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version 3.2.9 SSH Secure Shell
debug1: no match: 3.2.9 SSH Secure Shell
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "XXXXXXXXXXXXX" from file "/Users/XXXXX/.ssh/known_hosts"
debug3: load_hostkeys: loaded 0 keys
debug1: SSH2_MSG_KEXINIT sent
debug3: Received SSH2_MSG_IGNORE
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hm[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,twofish128-cbc,cast128-cbc,twofish-cbc,blowfish-cbc,aes192-cbc,aes256-cbc,twofish192-cbc,twofish256-cbc,arcfour
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,twofish128-cbc,cast128-cbc,twofish-cbc,blowfish-cbc,aes192-cbc,aes256-cbc,twofish192-cbc,twofish256-cbc,arcfour
debug2: kex_parse_kexinit: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96
debug2: kex_parse_kexinit: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug2: dh_gen_key: priv key bits set: 122/256
debug2: bits set: 496/1024
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug3: Received SSH2_MSG_IGNORE
debug1: Server host key: DSA XXXXXXXXXXXXXXXXXXXXXXXX
debug3: load_hostkeys: loading entries for host "XXXXXXXXXXXXX" from file "/Users/XXXXX/.ssh/known_hosts"
debug3: load_hostkeys: loaded 0 keys
debug3: load_hostkeys: loading entries for host "XXXXXXXXXXXX" from file "/Users/XXXXX/.ssh/known_hosts"
debug3: load_hostkeys: loaded 0 keys
The authenticity of host 'XXXXXXXXXXXXX (XXXXXXXXXXXX)' can't be established.
DSA key fingerprint is XXXXXXXXXXXXXXXXXXXXXXXX.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'XXXXXXXXXXXXX,XXXXXXXXXXXX' (DSA) to the list of known hosts.
debug2: bits set: 516/1024
debug1: ssh_dss_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: Received SSH2_MSG_IGNORE
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug3: Received SSH2_MSG_IGNORE
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /Users/XXXXX/.ssh/id_rsa (0x7f8e28500a10),
debug2: key: /Users/XXXXX/.ssh/id_dsa (0x0),
debug3: Received SSH2_MSG_IGNORE
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/XXXXX/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug3: Received SSH2_MSG_IGNORE
debug1: Authentications that can continue: password
debug3: start over, passed a different list password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup password
debug3: remaining preferred: ,keyboard-interactive,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
Jeśli mam poprawnie czyta wyjście (i nie może być) proces uzgadniania rozliczane za pomocą aes128-cbc do wymiany kluczy i hmac-md5 dla faktycznego szyfrowania sesji. Według the JSCH documentation (choć minimalna może być), oba te algorytmy są obsługiwane.
Mogę połączyć się z tym udziałem za pomocą narzędzia wiersza polecenia sftp i FileZilla, więc problem musi być albo z JSCH, albo z moją konfiguracją Java, ale nie mam pojęcia, co to jest.
wersja Java:
java version "1.7.0_71"
OpenJDK Runtime Environment
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)
wersja jsch:
<dependency>
<groupId>com.jcraft</groupId>
<artifactId>jsch</artifactId>
<version>0.1.51</version>
</dependency>
Z góry dzięki!
EDYTOWANIE: Wygląda na to, że a bug for this exact behaviour zostało złożone przeciwko JDK, ale zostało zamknięte bez żadnej rozdzielczości. Istnieje również an email thread między opiekunami JSCH i programistami JDK, który omawia problem, ale nie ma rozwiązania.
Wow. Wpadłem tutaj, żeby polecić JCE, ale wygląda na to, że wykonałeś pracę domową (nie, że to powinno być problem, ale tak samo). Jest szansa, że mógłbyś spróbować z Oracle Java (zamiast OpenJDK) 7? Nie chcę być niejasny, ale miałem pecha z OpenJDK w przeszłości. W tym momencie powiedziałbym, że Oracle Java byłaby co najmniej warta spróbowania. Być może będziesz musiał zainstalować JCE w tym miejscu (chwalę się tutaj słomkami, mając tylko nadzieję, że mogę pomóc) –
Kilka wyjaśnień: (1) Nie zainstalowałeś JCE, który jest już w pakiecie Javy. Zainstalowałeś "Unlimited Strength Policy", która jest * dodatkiem do * JCE. To ma znaczenie tylko wtedy, gdy pożądane/wynegocjowane szyfrowanie symetryczne przekracza 128 bitów, co wydaje się, że nie jest tak w twoim przypadku. (2) Twój handshake sftp wybrał 'aes128-cbc' dla * szyfrowania * i' hmac-md5' dla * sprawdzania integralności *; wymiana kluczy to Diffie-Hellman, uwierzytelnianie hosta to DSA, a uwierzytelnianie klienta wydaje się być hasłem. ... –
... (3) Użyte grupy DH i DSA wydają się być 1024-bitowe, co powinno być w porządku dla Java 7. Ale w przypadku, gdy dane wyjściowe debugowania nie są dokładne i wiarygodne, może pomóc uzyskać dostęp do sieci Śledź zwłaszcza próby JSCH z Wireshark lub podobnym, aby upewnić się i zobaczyć dokładnie, kiedy się nie powiedzie. Lub jeśli możesz przetestować z Javą 8, która rozszerza ograniczenia dla DH i DSA (chociaż możesz lub nie chcesz 8 z innych powodów). –