This is happening on OpenSSH for OpenBSD. LIttle backstory...
I have an Motorola Droid that I use SSHDroidPro to connect to it from various PCs (windows and OpenBSD) to transfer files. I upgraded to the Galaxy Nexus, and found that once I installed SSHDroidPro on it, I could no longer connect. I bought QuickSSHd, thinking that there was some issue with the old application, but could still not connect.. I have traced the issue back to sometime between November 20th, and December 16th. How do I know that? I had a VM from November 20th that I could SSH from to my new phone, but on my laptop, running a -current from December 16th fails. Here is the output from the November 20th VM, sshing to the phone: brakeb@openbsd-v0 ~ $ ssh -vvv root@192.168.1.46 OpenSSH_6.0-beta, OpenSSL 1.0.0e 6 Sep 2011 debug1: Reading configuration data /etc/ssh/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to 192.168.1.46 [192.168.1.46] port 22. debug1: Connection established. debug1: identity file /home/brakeb/.ssh/id_rsa type -1 debug1: identity file /home/brakeb/.ssh/id_rsa-cert type -1 debug1: identity file /home/brakeb/.ssh/id_dsa type -1 debug1: identity file /home/brakeb/.ssh/id_dsa-cert type -1 debug1: identity file /home/brakeb/.ssh/id_ecdsa type -1 debug1: identity file /home/brakeb/.ssh/id_ecdsa-cert type -1 debug1: Remote protocol version 2.0, remote software version dropbear_0.52 debug1: no match: dropbear_0.52 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.0-beta debug2: fd 3 setting O_NONBLOCK debug3: load_hostkeys: loading entries for host "192.168.1.46" from file "/home/brakeb/.ssh/known_hosts" debug3: load_hostkeys: found key type RSA in file /home/brakeb/.ssh/known_hosts:1 debug3: load_hostkeys: loaded 1 keys debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ssh-rsa debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ssh-ds s-cert-...@openssh.com,ssh-dss-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,z...@openssh.com,zlib debug2: kex_parse_kexinit: none,z...@openssh.com,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-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,3des-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes256-cbc,twofish256-cbc,twofish-cbc,twofish128-cbc,blowfish-cbc debug2: kex_parse_kexinit: aes128-ctr,3des-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes256-cbc,twofish256-cbc,twofish-cbc,twofish128-cbc,blowfish-cbc debug2: kex_parse_kexinit: hmac-sha1-96,hmac-sha1,hmac-md5 debug2: kex_parse_kexinit: hmac-sha1-96,hmac-sha1,hmac-md5 debug2: kex_parse_kexinit: none debug2: kex_parse_kexinit: none 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-ctr hmac-md5 none debug2: mac_setup: found hmac-md5 debug1: kex: client->server aes128-ctr hmac-md5 none debug2: dh_gen_key: priv key bits set: 129/256 debug2: bits set: 506/1024 debug1: sending SSH2_MSG_KEXDH_INIT debug1: expecting SSH2_MSG_KEXDH_REPLY debug1: Server host key: RSA 4f:1b:f4:c6:31:14:ce:7e:2e:53:00:de:98:20:de:8a debug3: load_hostkeys: loading entries for host "192.168.1.46" from file "/home/brakeb/.ssh/known_hosts" debug3: load_hostkeys: found key type RSA in file /home/brakeb/.ssh/known_hosts:1 debug3: load_hostkeys: loaded 1 keys debug1: Host '192.168.1.46' is known and matches the RSA host key. debug1: Found key in /home/brakeb/.ssh/known_hosts:1 debug2: bits set: 515/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/brakeb/.ssh/id_rsa (0x0) debug2: key: /home/brakeb/.ssh/id_dsa (0x0) debug2: key: /home/brakeb/.ssh/id_ecdsa (0x0) debug3: input_userauth_banner QuickSSHD for Android debug1: Authentications that can continue: password debug3: start over, passed a different list password debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup passworddebug2: we sent a password packet, wait for reply debug1: Authentication succeeded (password). Authenticated to 192.168.1.46 ([192.168.1.46]:22). debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Entering interactive session. debug2: callback start debug2: client_session2_setup: id 0 debug2: fd 3 setting TCP_NODELAY debug3: packet_set_tos: set IP_TOS 0x10 debug2: channel 0: request pty-req confirm 1 debug2: channel 0: request shell confirm 1 debug2: callback done debug2: channel 0: open confirm rwindow 24576 rmax 32768 debug2: channel_input_status_confirm: type 99 id 0 debug2: PTY allocation request accepted on channel 0 debug2: channel_input_status_confirm: type 99 id 0 debug2: shell request accepted on channel 0 root@android:/data/data/com.teslacoilsw.quicksshd/home # debug2: client_check_window_change: changed debug2: channel 0: request window-change confirm 0 root@android:/data/data/com.teslacoilsw.quicksshd/home # debug3: remaining preferred: ,keyboard-interactive,password debug3: authmethod_is_enabled password debug1: Next authentication method: password root@192.168.1.46's password: debug3: packet_send2: adding 64 (len 55 padlen 9 extra_pad 64) And here is the output from the December 16th snapshot on my laptop: $ ssh -vvv 192.168.1.46 OpenSSH_6.0-beta, OpenSSL 1.0.0e 6 Sep 2011 debug1: Reading configuration data /etc/ssh/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to 192.168.1.46 [192.168.1.46] port 22. *sticks for about 45 seconds* debug1: connect to address 192.168.1.46 port 22: Connection timed out ssh: connect to host 192.168.1.46 port 22: Connection timed out And that it... I can connect to the phone with PuTTY on a Windows machine with no issues... But here's the kicker... I booted up my old Droid, just to use the Wifi connection (plan on using it as a SIP), and used the December 16th snapshot to try and SSH, and it connects to the DROID just fine. I have changed the passwords from easy to more than 20 characters. I can ping the box, and the nmap scan that I use on Windows shows that port 22 is open (I can provide that if you need me to), but nothing I can do will get it to connect to the Galaxy Nexus on my laptop... I wondered if there is something in the new 'Ice Cream Sandwich' Android 4.0... I have contacted the developers of SSHDroidPro, and QuickSSHd to ask them if they have had any issues, but I have not heard anything back...
