SSH authentication failing for t2-vm about t2-vm

[tcr]

Am I correct in that /etc/dropbear/authorized_keys on the VM lists the same key as <home directory>\.tessel\id_rsa.pub on your host box? This would be the key generated for the Tessel CLI.

The VM connection is functionally equivalent to this (on my machine):

ssh root@<vm ip address> -i ~/.tessel/id_rsa

Let me know if an SSH connection with the equivalent Windows key path <home dir>\.tessel\id_rsa. Perhaps key is actually being written to a bogus home directory on Windows, or the SSH behavior differs. The VM network is working at least, since you're seeing the mdns response in t2 list.

Thanks for looking into this. I will attempt to reproduce this tomorrow on a Windows box and update you.

[ondreian]

@tcr /etc/dropbear/authorized_keys on the vm is the same as %HOMEPATH%\.tessel\id_rsa.pub

I spent some time debugging the raw SSH connection this morning, and found some interesting results

first t2 list attempt

C:\>t2 list
INFO Scanning for connections...
{ [Error: Timed out while waiting for handshake] level: 'client-timeout' }
INFO LAN CONNECTION ip:  10.100.10.14 , name:  Tessel-0800277088D2 , Authorized:  false

First Attempt to raw ssh in:

C:\>ssh [email protected] -i C:\Users\Benjamin\.tessel\id_rsa -v
OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007
debug1: Connecting to 10.100.10.14 [10.100.10.14] port 22.
debug1: connect to address 10.100.10.14 port 22: Attempt to connect timed out without establishing a connection
ssh: connect to host 10.100.10.14 port 22: Bad file number

It wasn't even getting to the key exchange part of the authentication process.

So next I decided to see if this was because the IP address wasn't being forwarded properly to the virtual host.

C:\>ping 10.100.10.14

Pinging 10.100.10.14 with 32 bytes of data:
***Reply from 10.100.10.2: Destination host unreachable.***
Reply from 10.100.10.14: bytes=32 time=1ms TTL=64
Reply from 10.100.10.14: bytes=32 time<1ms TTL=64
Reply from 10.100.10.14: bytes=32 time<1ms TTL=64

After pinging it however, I could SSH in.

C:\>ssh [email protected] -i C:\Users\Benjamin\.tessel\id_rsa -v
OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007
debug1: Connecting to 10.100.10.14 [10.100.10.14] port 22.
debug1: Connection established.
debug1: identity file C:\\Users\\Benjamin\\.tessel\\id_rsa type 1
debug1: Remote protocol version 2.0, remote software version dropbear_2014.65
debug1: no match: dropbear_2014.65
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
The authenticity of host '10.100.10.14 (10.100.10.14)' can't be established.
RSA key fingerprint is XXX                           
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.100.10.14' (RSA) to the list of known hosts.
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: C:\\Users\\Benjamin\\.tessel\\id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.


BusyBox v1.23.2 (2015-04-22 23:25:48 UTC) built-in shell (ash)

Tessel 2  /  Built on OpenWrt
root@Tessel-0800277088D2:~# 

And t2 list also worked fine at this point.

C:\>t2 list
INFO Scanning for connections...
INFO LAN CONNECTION ip:  10.100.10.14 , name:  Tessel-0800277088D2 , Authorized:  true

So, it i seems it isn't really a dropbear problem at all, more some sort of networking problem.

I appreciate the assistance with this.

[tcr]

@ondreian Good news, your branch works on my Windows box. I appreciate the refactoring that went into it! I was able to replicate the issue of t2 list not resolving, but not the issue in your most recent post (which may be a red herring). Let's see if this fixes both.

t2-cli uses the hostname itself and not the IP address to connect to the machine. This works on machines that have mDNS servers (bonjour, avahi) but should not be expected to work on Windows; Tessel-080027708D2.local only resolves if your system is aware of it, while the IP address works always.

Would you try this branch of t2-cli with these changes? https://github.com/tessel/t2-cli/tree/tcr-iphost That was all I had to do to get listing and running code on the VM working on my box.

[ondreian]

That seems to have fixed it. Much appreciated.

I'd like to verify my branch also works with Linux as expected before I submit a PR, I'll see if I cannot get my hands on a Linux box today to test and i'll let you know the results.

[tcr]

Thanks @ondreian. I'll be able to verify it works on all three OSes on my end also.