OpenSSH 6.0-beta testing issue

2011-12-18 Thread Bryan 
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
debu

Re: OpenSSH 6.0-beta testing issue

2011-12-19 Thread Bryan 
On Sun, Dec 18, 2011 at 22:47, Bryan  wrote:
> 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. B I upgraded to
> the Galaxy Nexus, and found that once I installed SSHDroidPro on it, I
> could no longer connect. B 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. B How do I know that? B 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.
>

>
> 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... B 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. B I
> can ping the box, and the nmap scan B 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... B 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...

There have been 4 changes made to OpenSSH between November 20th and
December 16th.

http://www.freshbsd.org/search?project=openbsd&q=ssh

DroidSSHPro and QuickSSHd both utilize the Dropbear implementation of
SSH, which looks like the guy took pieces from here and there, and
cobbled together something, which might be why it isn't working.

I am willing to test patches, if anyone wants to toss something over
the fence...  since I appear to be the only one having an issue.  If
you have a Galaxy Nexus, and use one of those apps to SSH, please give
it a try with a later snapshot...

Re: OpenSSH 6.0-beta testing issue

2011-12-19 Thread Stuart Henderson 
On 2011-12-19, Bryan  wrote:
> 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.

I find it hard to believe that this...

> $ 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*

...would have anything to do with the version of OpenSSH, it just
looks like the TCP connection is failing (firewall? something else?
consider what things might be different between the VM and your laptop).

What happens if you "telnet 192.168.1.46 22"?