Jsch with spongycastle rather than bouncycastle on Android

Question

I currently have an Android application connecting to my router via ssh using a password. I'm looking to improve this so I can use keys but I am having real issues. From what I understand the version of bouncycastle included with android is a crippled version and because of this ssh keys don't work with jsch. I have looked at spongycastle which claims to be a fuller implementation. Below is the result which is basically the same as using bouncycastle, Auth Fail.


10-26 18:18:23.528: INFO/System.out(10642): Log(jsch,1): Connecting to 192.168.88.1 port 22
10-26 18:18:23.538: INFO/System.out(10642): Log(jsch,1): Connection established
10-26 18:18:23.548: INFO/System.out(10642): Log(jsch,1): Remote version string: SSH-2.0-ROSSSH
10-26 18:18:23.548: INFO/System.out(10642): Log(jsch,1): Local version string: SSH-2.0-JSCH-0.1.44
10-26 18:18:23.548: INFO/System.out(10642): Log(jsch,1): CheckCiphers: aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,arcfour,arcfour128,arcfour256
10-26 18:18:23.618: INFO/System.out(10642): Log(jsch,1): SSH_MSG_KEXINIT sent
10-26 18:18:23.618: INFO/System.out(10642): Log(jsch,1): SSH_MSG_KEXINIT received
10-26 18:18:23.628: INFO/System.out(10642): Log(jsch,1): kex: server->client aes128-cbc hmac-md5 none
10-26 18:18:23.628: INFO/System.out(10642): Log(jsch,1): kex: client->server aes128-cbc hmac-md5 none
10-26 18:18:23.688: INFO/System.out(10642): Log(jsch,1): SSH_MSG_KEXDH_INIT sent
10-26 18:18:23.688: INFO/System.out(10642): Log(jsch,1): expecting SSH_MSG_KEXDH_REPLY
10-26 18:18:24.058: INFO/System.out(10642): Log(jsch,1): ssh_dss_verify: signature true
10-26 18:18:24.058: INFO/System.out(10642): Log(jsch,2): Permanently added '192.168.88.1' (DSA) to the list of known hosts.
10-26 18:18:24.058: INFO/System.out(10642): Log(jsch,1): SSH_MSG_NEWKEYS sent
10-26 18:18:24.058: INFO/System.out(10642): Log(jsch,1): SSH_MSG_NEWKEYS received
10-26 18:18:24.078: INFO/System.out(10642): Log(jsch,1): SSH_MSG_SERVICE_REQUEST sent
10-26 18:18:24.088: INFO/System.out(10642): Log(jsch,1): SSH_MSG_SERVICE_ACCEPT received
10-26 18:18:24.108: INFO/System.out(10642): Log(jsch,1): Authentications that can continue: publickey,keyboard-interactive,password
10-26 18:18:24.108: INFO/System.out(10642): Log(jsch,1): Next authentication method: publickey
10-26 18:18:24.108: INFO/System.out(10642): Log(jsch,1): Authentications that can continue: password
10-26 18:18:24.118: INFO/System.out(10642): Log(jsch,1): Next authentication method: password
10-26 18:18:24.128: INFO/System.out(10642): Log(jsch,1): Disconnecting from 192.168.88.1 port 22
10-26 18:18:24.138: WARN/System.err(10642): com.jcraft.jsch.JSchException: Auth fail

There's not a great deal of logging information from jsch to help me work out what's wrong.

I think I'm using pretty standard code for this:



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

In OnCreate I'm removing the original bouncycastle provider



        Security.removeProvider("BC");

Then I add the identity just before trying to connect



        jsch.addIdentity(key_filename);

    Properties sshProp = new Properties();
    sshProp.put("StrictHostKeyChecking", "no");
    session.setConfig(sshProp);
    session.connect();

Has anyone done this successfully? Am I forgetting something?

Edit point additional info:

As I said in the comment I'm now suspecting that the key isn't even being tried when I switch the key and test on sshd version OpenSSH_5.3p1 Debian-3ubuntu7


debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: dh_gen_key: priv key bits set: 122/256
debug2: bits set: 519/1024
debug1: expecting SSH2_MSG_KEXDH_INIT
debug2: bits set: 537/1024
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: monitor_read: 5 used once, disabling now
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user root service ssh-connection method none
debug1: attempt 0 failures 0
debug2: parse_server_config: config reprocess config len 638
debug2: input_userauth_request: setting up authctxt for root
debug2: input_userauth_request: try method none
debug2: monitor_read: 7 used once, disabling now
debug1: PAM: initializing for "root"
debug1: PAM: setting PAM_RHOST to "nexus"
debug1: PAM: setting PAM_TTY to "ssh"
debug2: monitor_read: 50 used once, disabling now
debug2: monitor_read: 3 used once, disabling now
Failed none for root from 192.168.88.31 port 37807 ssh2
debug1: userauth-request for user root service ssh-connection method password
debug1: attempt 1 failures 0
debug2: input_userauth_request: try method password
debug1: PAM: password authentication failed for root: Authentication failure
Failed password for root from 192.168.88.31 port 37807 ssh2
Received disconnect from 192.168.88.31: 3: com.jcraft.jsch.JSchException: Auth fail
debug1: do_cleanup
debug1: do_cleanup
debug1: PAM: cleanup

I can see no attempt to use the key, whereas from a pc



debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 1 failures 0
debug2: input_userauth_request: try method publickey
debug1: test whether pkalg/pkblob are acceptable
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys2
debug1: fd 4 clearing O_NONBLOCK
debug1: matching key found: file /root/.ssh/authorized_keys2, line 2

I can see the key method being used. Below is the code I'm using for testing, not pretty but functional. I know it's horrible but password does contain the filename and path of the key to be used when authtype == AUTHENTICATION_METHOD_KEY



public static String testSSHCommand ( String username, String password, String hostname, int port, String command, int authtype) throws Exception {    

    JSch jsch = new JSch();

    JSch.setLogger(new Logger() {
            public boolean isEnabled(int i) {
                return true;
            }

            public void log(int i, String s) {
                System.out.println("Log(jsch," + i + "): " + s);
            }
    });


    if (authtype != AUTHENTICATION_METHOD_PASSWORD) {
        Log.v("AUTHMETHOD","authmethod was "+authtype+" with key filename of "+password);
        jsch.addIdentity(password);
    } 

    Session session = jsch.getSession(username, hostname, 22);

    if (authtype != AUTHENTICATION_METHOD_KEY) {
        session.setPassword(password);
    }


    Properties prop = new Properties();
    prop.put("StrictHostKeyChecking", "no");
    session.setConfig(prop);

    session.connect();

    if (session.isConnected() ) {
        ChannelExec channelssh = (ChannelExec)          
        session.openChannel("exec");      
        ByteArrayOutputStream os = new ByteArrayOutputStream();
        channelssh.setOutputStream(os);
        channelssh.setCommand(command);
        channelssh.connect();        
        channelssh.disconnect();

        return os.toString();
    } else {
        return "";
    }
}

I suspect you are using a wrong public key. Does the login with the same key files (public + private) work from a normal PC Java program? — Paŭlo Ebermann, Oct 26 '11 at 23:29
I don't do PC based java development, however the keys are fine I can use them on my pc to ssh into a server box to test. I'm actually beginning to suspect that the keys aren't even being tried. (see edit) — Fuzzy, Oct 27 '11 at 06:47
Comparing this with a normal PC Java would help to isolate the problem, i.e. if it is related to your crypto provider or to your own code. — Paŭlo Ebermann, Oct 27 '11 at 12:13
I've tried without spongycastle too - same results. Perhaps I'm missing some obvious step, since the key exchange isn't attempted (it seems) Is there a way to be more debug info from jsch? This is on android 2.3.3 — Fuzzy, Oct 27 '11 at 12:46
I don't know much about Android, but showing your complete JSch accessing code could help to find the problem (if it is there). — Paŭlo Ebermann, Oct 27 '11 at 13:05

score 1 · Answer 1 · answered Oct 29 '11 at 20:56

I tested your method by wrapping it into a class with main method, and with this, it works in a normal Java 6 JRE (no BouncyCastle), with JSch-0.1.45 (a modified version with more logging output) and "OpenSSH_5.8p1 Debian-1ubuntu3" sshd.

I added a session.disconnect() and some sleeps to the code, though.

I have no Android here to see if this would make any difference.

Here is my local output:

authmethod was 2 with key filename of /home/paulo/.ssh/id_rsa
Log(jsch,1): Connecting to localhost port 22
Log(jsch,1): Connection established
Log(jsch,1): Remote version string: SSH-2.0-OpenSSH_5.8p1 Debian-1ubuntu3
Log(jsch,1): Local version string: SSH-2.0-JSCH-0.1.45
Log(jsch,1): CheckCiphers: aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,arcfour,arcfour128,arcfour256
Log(jsch,1): aes256-ctr is not available.
Log(jsch,1): aes192-ctr is not available.
Log(jsch,1): aes256-cbc is not available.
Log(jsch,1): aes192-cbc is not available.
Log(jsch,1): arcfour256 is not available.
Log(jsch,1): CheckKexes: diffie-hellman-group14-sha1
Log(jsch,1): diffie-hellman-group14-sha1 is not available.
Log(jsch,1): SSH_MSG_KEXINIT sent
Log(jsch,1): SSH_MSG_KEXINIT received
Log(jsch,1): kex: server->client aes128-ctr hmac-md5 none
Log(jsch,1): kex: client->server aes128-ctr hmac-md5 none
Log(jsch,1): SSH_MSG_KEXDH_INIT sent
Log(jsch,1): expecting SSH_MSG_KEXDH_REPLY
Log(jsch,1): ssh_rsa_verify: signature true
Log(jsch,2): Permanently added 'localhost' (RSA) to the list of known hosts.
Log(jsch,1): SSH_MSG_NEWKEYS sent
Log(jsch,1): SSH_MSG_NEWKEYS received
Log(jsch,1): SSH_MSG_SERVICE_REQUEST sent
Log(jsch,1): SSH_MSG_SERVICE_ACCEPT received
Log(jsch,1): Authentications that can continue: publickey,keyboard-interactive,password
Log(jsch,1): Next authentication method: publickey
Log(jsch,1): Authentication succeeded (publickey).
Log(jsch,0): packet received, type: 91
Log(jsch,1): SSH_MSG_CHANNEL_OPEN_CONFIRMATION received, channel: 0
Log(jsch,0): packet received, type: 94
Log(jsch,1): SSH_MSG_CHANNEL_DATA received, channel: 0, len: 13
Log(jsch,0): packet received, type: 96
Log(jsch,1): SSH_MSG_CHANNEL_EOF received, channel: 0
Log(jsch,0): packet received, type: 98
Log(jsch,1): SSH_MSG_CHANNEL_REQUEST received, channel: 0, type: [B@1ad086a, want reply: false
Log(jsch,0): packet received, type: 97
Log(jsch,1): SSH_MSG_CHANNEL_CLOSE received, channel: 0
Log(jsch,1): Disconnecting from localhost port 22
Log(jsch,1): Caught an exception, leaving main loop due to Socket closed
Output: »Hallo, Welt!
«

(I called the program with arguments paulo -key /home/paulo/.ssh/id_rsa localhost 22 hello, so it executes the default Hello World program on the target machine, and in German, because this is my configured locale.)

So are we saying that jsch doesn't work with keys on android? — Fuzzy, Oct 31 '11 at 09:24
I'm saying that I don't know the reason. You could try my test program with your key on your computer for comparison, though. (And maybe test the more-debugging-output version of JSch in the linked GitHub repository, to see if you get more information.) — Paŭlo Ebermann, Oct 31 '11 at 13:13
I'm being extremely dim today, I can't find your updated jar from the link you gave, could you provide the direct link? — Fuzzy, Nov 02 '11 at 07:30
I'm not sure there is a jar, though you can compile the source code yourself (use `ant compile` in the root directory). I'll have a look if I can generate a jar, though probably not today. — Paŭlo Ebermann, Nov 02 '11 at 10:35

Jsch with spongycastle rather than bouncycastle on Android

1 Answers1