Excepción de SSHJ de Android al conectarse () – "Implementación de KeyFactory ECDSA no encontrada"

Estoy intentando abrir una sesión de cliente SSH desde mi aplicación de Android. Tratando de conectar a un dispositivo en la red local (un Pi de frambuesa). Estoy utilizando la versión de la biblioteca SSHJ 0.10.0. Se ssh.connect() error en la llamada ssh.connect() , con un TransportException que es causado en última instancia por un NoSuchAlgorithmException . Haga referencia al árbol de excepciones a continuación.

 SSHClient ssh = new SSHClient(new AndroidConfig()); Session session = null; try { //ssh.loadKnownHosts(); // Exception thrown on this line ssh.connect("192.168.1.109", 22); // Doesn't reach below ssh.authPassword("user", "password"); session = ssh.startSession(); } catch (net.schmizz.sshj.transport.TransportException ex) { ; } 

Árbol de excepciones:

 net.schmizz.sshj.transport.TransportException net.schmizz.sshj.common.SSHException net.schmizz.sshj.common.SSHRuntimeException java.security.GeneralSecurityException: java.security.NoSuchAlgorithmException: KeyFactory ECDSA implementation not found java.security.NoSuchAlgorithmException: KeyFactory ECDSA implementation not found 

Información del sistema:

 SSHJ library : v0.10.0 Android device : Galaxy Note 3 running Android 4.4.2 

Utilicé la ayuda de la dependencia del maven en el estudio androide para traer en el JAR de SSHJ y él tiró en las tres bibliotecas siguientes además del frasco de SSHJ v0.10.0 …

 bouncy castle... bcpkix-jdk15on-1.50.jar bcprov-jdk15on-1.50.jar logging.... slf4j-api-1.7.7.jar 

No tiene ni idea de por dónde empezar con esta excepción … cualquier sugerencia apreciada! Gracias.

ACTUALIZACIÓN: 31-Oct-2014

Como sugiere LeeDavidPainter , he incluido el SpongyCastle 1.51.0 JAR y agregado esta línea en la parte superior:

 Security.insertProviderAt(new org.spongycastle.jce.provider.BouncyCastleProvider(), 1); 

Ahora estoy recibiendo una excepción diferente en la misma línea:

 net.schmizz.sshj.transport.TransportException net.schmizz.sshj.common.SSHException net.schmizz.sshj.common.SSHRuntimeException java.security.GeneralSecurityException: java.security.spec.InvalidKeySpecException: key spec not recognised java.security.spec.InvalidKeySpecException: key spec not recognised 

También note que probé la línea siguiente también, con el mismo resultado:

 Security.addProvider(new org.spongycastle.jce.provider.BouncyCastleProvider()); 

Tengo otra aplicación en mi teléfono que básicamente está haciendo exactamente lo que quiero lograr – su llamado RaspberryPiController – se conecta a su RPi a través de SSH con nombre de usuario y contraseña auth. Esto funciona bien, por lo que parece que no es un problema de red.

Android incluye una versión reducida de BouncyCastle que no incluye los algoritmos ECDSA. Así que aunque incluya la versión completa en su ruta de clase, la versión de runtime de Android será recogida y utilizada.

Es posible que desee ver http://rtyley.github.io/spongycastle/ que fue creado para evitar esto, es una versión reenvasada de Bouncycastle que se puede instalar como un proveedor separado de JCE en Android. Simplemente instálelo como proveedor predeterminado de JCE antes de intentar conectarse con SSHJ (no probado).

 Security.insertProviderAt(new org.spongycastle.jce.provider.BouncyCastleProvider(), 1); 

Baja a sshj 0.9.0 aquí: http://mvnrepository.com/artifact/net.schmizz/sshj/0.9.0

El problema parece haber sido introducido en 0.10.x. También, he intentado el otro abastecedor de JCE pero conseguí en el mismo apuro.

Probablemente Jsch funcionó porque no soporta los algoritmos de la curva elíptica para SSH AFAIK. Si no necesita algoritmos de curva elíptica, entonces esa es su respuesta.

No se pudo llegar a ninguna parte con este problema en SSHJ, por lo que decidió dar JSch un intento que ofrece la misma funcionalidad. Está disponible como un repo del maven también – utilicé jsch la versión 0.1.51 ('com.jcraft: jsch: 0.1.51').

Funcionó por primera vez con este fragmento de código;

 import com.jcraft.jsch.ChannelExec; import com.jcraft.jsch.JSch; import com.jcraft.jsch.JSchException; import java.io.ByteArrayOutputStream; import java.util.Properties; JSch jsch = new JSch(); com.jcraft.jsch.Session session = null; String result = ""; try { session = jsch.getSession("user", "192.168.1.109", 22); session.setPassword("password"); // Avoid asking for key confirmation Properties prop = new Properties(); prop.put("StrictHostKeyChecking", "no"); session.setConfig(prop); session.connect(); // SSH Channel ChannelExec channel = (ChannelExec)session.openChannel("exec"); ByteArrayOutputStream stream = new ByteArrayOutputStream(); channel.setOutputStream(stream); // Execute command channel.setCommand("ls -ltr"); channel.connect(1000); java.lang.Thread.sleep(500); // this kludge seemed to be required. channel.disconnect(); result = stream.toString(); } catch (JSchException ex) { String s = ex.toString(); System.out.println(s); } catch (InterruptedException ex) { String s = ex.toString(); System.out.println(s); } finally { if (session != null) session.disconnect(); } 

Se siente como una implementación más robusta cuando se utiliza en comparación con SSHJ – o esta impresión podría ser causada por ellos la selección de tiempo de espera muy conservador. Por ejemplo, si el dispositivo de destino está desactivado, la llamada session.connect (), por defecto, seguirá intentando conectarse por algo como 20 segundos antes de darse por vencido.

  • JSch: Cómo ssh en un servidor utilizando ssh-keys
  • ¿Es posible desarrollarse para Android en Android?
  • ejecutar el comando SSH en Rasperry Pi con la aplicación para Android
  • Jsch con spongycastle en lugar de bouncycastle en Android
  • Múltiples comandos a través de Jsch Shell
  • Uso de ConnectBot con intentos
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.