Scp file using balena tunnel

Hi,

I tried to scp a file to a device thru balena tunnel but got this error

  • /home/balena-cli/balena tunnel 079de59 -p 22222:40924
    [Info] Opening a tunnel to 079de59851a3f2ba47a86b233e9e54d9…
    [Info] - tunnelling localhost:40924 to 079de59851a3f2ba47a86b233e9e54d9:22222
    [Info] Waiting for connections…
  • scp -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -q -P 40924 /var/opt/data.db.079de59 root@127.0.0.1:/var/lib/docker/volumes/1_data/_data/
    [Error] 127.0.0.1:60894 => 127.0.0.1:40924 ===> 10.240.0.5:22222 :: Device is not listening on port 22222

The scp is trying to connect to the device with the wrong ip “10.240.0.5”. I saw the 10.240.x.x address when I am using the balena cloud. Is tunneling to device supported by openbalena?

Thanks
Patrick

1 Like

@pli

Yes openBalena supports tunnelling SSH as you are doing. The IP you’re seeing is the IP the device gets from the VPN which is the channel the tunnel is running over. I am not sure why your device is not listening on port 22222 though.

I would try an actual SSH session first to make sure that works OK, then try SCP.

@richbayliss

I got this error

[root@centos bin]# ssh -p 40924 root@127.0.0.1
ssh_exchange_identification: Connection closed by remote host

[root@centos bin]# ssh -vvv -p 40924 root@127.0.0.1
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017
debug1: Reading configuration data /root/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 58: Applying options for *
debug2: resolving “127.0.0.1” port 40924
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 127.0.0.1 [127.0.0.1] port 40924.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4
ssh_exchange_identification: Connection closed by remote host

Thanks

@pli is your device accessible on your local network? In which case, could you try sshing directly through its local IP? That might help figure out if the ssh server is actually running on the device.

@pcarranzav,

Yes I can ssh directly to the device using the local ip.

[root@centos db]# ssh -p 22222 root@10.0.3.70
The authenticity of host ‘[10.0.3.70]:22222 ([10.0.3.70]:22222)’ can’t be established.
RSA key fingerprint is SHA256:Ukl2KDHg5KVMISM5cegrScH5jw4K3/xNGdn4ycfp5RY.
RSA key fingerprint is MD5:57:b4:71:de:33:c2:aa:11:63:ca:20:0d:fa:2d:52:b1.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘[10.0.3.70]:22222’ (RSA) to the list of known hosts.
root@0f67af9:~#

But ssh via the tunnel is not working

[root@centos ~]# /home/balena-cli/balena tunnel 0f67af9 -p 22222:40924
[Info] Opening a tunnel to 0f67af92fb599439ad0a33831a8e24e4…
[Info] - tunnelling localhost:40924 to 0f67af92fb599439ad0a33831a8e24e4:22222
[Info] Waiting for connections…

[root@centos db]# ssh -p 40924 root@127.0.0.1
[Error] 127.0.0.1:37978 => 127.0.0.1:40924 ===> 10.240.0.10:22222 :: Device is not listening on port 22222

Thanks
Patrick

Given the error message “Device is not listening on port 22222”, as a further debugging step it may be helpful to run "netstat -ant" on the device’s host OS command prompt to confirm that the ssh server is listening on :::22222. Here I get the following, on a NUC running balenaOS 2.32.0:

root@b1878c6:~# netstat -ant
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
...
tcp        0      0 :::22222                :::*                    LISTEN
tcp        0      0 ::ffff:192.168.1.118:22222 ::ffff:192.168.1.110:53671 ESTABLISHED
tcp        0    752 ::ffff:100.64.26.12:22222 ::ffff:52.4.252.97:54634 ESTABLISHED

I am using balenaCloud instead of openBalena, but I think the operation of balena tunnel is the same. I tried the same commands as you:

$ balena tunnel <uuid> -p 22222:40924
[Info]    Opening a tunnel to <uuid>...
[Info]     - tunnelling localhost:40924 to <uuid>:22222
[Info]    Waiting for connections...
[Logs]    127.0.0.1:53900 => 127.0.0.1:40924 ===> 100.64.26.12:22222
$ ssh -p 40924 root@127.0.0.1
root@b1878c6:~# cat /etc/issue
balenaOS 2.32.0 \n \l

hello please can you help me i want to begin this system balena but type this
and have this error
root@e47da60:~# git push balena master
bash: git: command not found
i need enable something before thank you

Hi @mobiplay , you have posted this on an active thread with a different problem that we are actively working on. Could you open a new thread and post on there ?
I will be with you as soon as it comes up.

@pdcastroPreformatted text

The device is listening to port 22222

[root@centos ~]# ssh -p 22222 root@10.0.3.70
root@0f67af9:~# netstat -ant|grep 22222
tcp        0      0 :::22222                :::*                    LISTEN
tcp        0      0 ::ffff:10.0.3.70:22222  ::ffff:10.0.0.107:33152 ESTABLISHED

For a few times, I noticed after the ssh connection to the device thru the tunnel failed, netstat -ant showed a connection between 10.240.0.10 and 10.240.0.1. Can it be a timing issue?

root@0f67af9:~# netstat -ant|grep 22222
tcp 0 0 :::22222 :::* LISTEN
tcp 0 0 ::ffff:10.240.0.10:22222 ::ffff:10.240.0.1:35988 ESTABLISHED
tcp 0 0 ::ffff:10.0.3.70:22222 ::ffff:10.0.0.107:33152 ESTABLISHED

Thanks

@pli, comparing your balena tunnel output with mine, I’ve now noticed that mine attempts to connect to a public IPv4 address (100.64.26.12:22222), whereas yours attempts to connect to a private address (10.240.0.10:22222), where the private address looks also different from your laptop/device subnet (10.0.3.70):

# mine, public IP "100.64.26.12"
[Logs]    127.0.0.1:53900 => 127.0.0.1:40924 ===> 100.64.26.12:22222
# yours, private IP "10.240.0.10"
[Error] 127.0.0.1:37978 => 127.0.0.1:40924 ===> 10.240.0.10:22222 :: Device is not listening on port 22222

What I now wonder is whether your local routers or firewalls are setup to route, or not to block, between 10.0.3.70 (your laptop + device subnet, I assume) and 10.240.0.10 (your openBalena subnet, I assume).