Sto tentando di utilizzare JSCH per caricare un file su una condivisione remota SFTP. Ogni volta che tento di connettersi alla condivisione da dentro il mio codice, ottengo un'eccezione che sembra qualcosa di simile:Java 1.7 + JSCH: java.security.InvalidKeyException: la chiave è troppo lunga per questo algoritmo
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]
Ho visto posts that describe this error durante l'aggiornamento a Java 8, ma siamo ancora in Java 7 e non ne so abbastanza del supporto per la crittografia di Java per sapere se questo è importante.
Alcune persone suggeriscono di installare JCE (Java Cryptography Extensions) per risolvere questo problema, quindi ho dato un colpo, ma ottengo ancora lo stesso errore dopo aver copiato i file jar appropriati nella directory/libs/security e riavviare l'applicazione . Abbiamo confermato che JCE è stato installato eseguendo this script e notando che l'eccezione non è stata generata.
Ho anche provato a connettere la condivisione SFTP remota dal terminale utilizzando il comando sftp in modalità dettagliata. Ecco che cosa ho ottenuto:
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,[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
Se sto leggendo l'uscita in modo corretto (e non può essere) il processo di handshake scelto di utilizzare aes128-cbc per lo scambio di chiave e hmac-md5 per la crittografia della sessione attuale. Secondo the JSCH documentation (anche se minimo può essere), entrambi questi algoritmi sono supportati.
Posso collegarmi a questa condivisione sia con l'utilità da riga di comando sftp sia con FileZilla, quindi il problema deve essere con JSCH o con la mia configurazione Java, ma non riesco a capire cosa sia.
versione Java:
java version "1.7.0_71"
OpenJDK Runtime Environment
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)
versione JSch:
<dependency>
<groupId>com.jcraft</groupId>
<artifactId>jsch</artifactId>
<version>0.1.51</version>
</dependency>
Grazie in anticipo!
MODIFICA: Sembra che a bug for this exact behaviour sia stato archiviato contro il JDK, ma è stato chiuso senza risoluzione. C'è anche an email thread tra i manutentori di JSCH e gli sviluppatori JDK che discute il problema, ma non ha alcuna risoluzione.
Wow. Sono venuto qui per raccomandare JCE, ma sembra che tu abbia fatto i compiti (non che avrebbe dovuto comunque essere il problema, ma lo stesso). Qualche possibilità di provarlo con Oracle Java (invece di OpenJDK) 7? Non intendo essere vago, ma in passato ho avuto sfortuna con OpenJDK. A questo punto, direi che Oracle Java varrebbe la pena provare almeno. Potrebbe essere necessario installare JCE in esso (sto cercando di afferrare le cannucce qui. Spero solo di poter aiutare) –
Alcuni chiarimenti: (1) Non hai installato JCE, che è già nel pacchetto Java. Hai installato la "Policy illimitata resistenza" che è un * addon a * JCE. Questo fa la differenza solo se la crittografia simmetrica desiderata/negoziata è di oltre 128 bit, il che sembra che il tuo caso non lo sia. (2) L'handshake sftp ha selezionato 'aes128-cbc' per * encryption * e' hmac-md5' per * integrity-checking *; lo scambio di chiavi è Diffie-Hellman, l'autenticazione dell'host è DSA e l'autenticazione del client sembra essere una password. ... –
... (3) I gruppi DH e DSA utilizzati sembrano essere 1024 bit, il che dovrebbe andare bene per Java 7. Ma nel caso in cui l'output di debug non sia esatto e affidabile, potrebbe essere utile ottenere una rete Traccia in particolare del tentativo di Jsch con Wireshark o simili per essere sicuro e vedere esattamente quando fallisce. Oppure, se riesci a testare con Java 8, questo espande i limiti per DH e DSA (sebbene tu possa o non voglia 8 per altri motivi). –