10 replies to this topic

[gusto]

I installed OpenPLi 9 on Formuler4 for the first time. The box uses a classic ETH network card and also a virtual TUN.

ETH 192.168.1.54
TUN 10.8.0.128

I want to login to the box via SSH and TUN, but it doesn't work

 ssh root@10.8.0.128 -v
OpenSSH_8.9p1 Ubuntu-3ubuntu0.4, OpenSSL 3.0.2 15 Mar 2022
debug1: Reading configuration data /home/gusto/.ssh/config
debug1: /home/gusto/.ssh/config line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to 10.8.0.128 [10.8.0.128] port 22.
debug1: Connection established.
debug1: identity file /home/gusto/.ssh/id_rsa type 0
debug1: identity file /home/gusto/.ssh/id_rsa-cert type -1
debug1: identity file /home/gusto/.ssh/id_ecdsa type -1
debug1: identity file /home/gusto/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/gusto/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/gusto/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/gusto/.ssh/id_ed25519 type -1
debug1: identity file /home/gusto/.ssh/id_ed25519-cert type -1
debug1: identity file /home/gusto/.ssh/id_ed25519_sk type -1
debug1: identity file /home/gusto/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/gusto/.ssh/id_xmss type -1
debug1: identity file /home/gusto/.ssh/id_xmss-cert type -1
debug1: identity file /home/gusto/.ssh/id_dsa type -1
debug1: identity file /home/gusto/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.4
debug1: Remote protocol version 2.0, remote software version dropbear_2020.81
debug1: compat_banner: no match: dropbear_2020.81
debug1: Authenticating to 10.8.0.128:22 as 'root'
debug1: load_hostkeys: fopen /home/gusto/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: rsa-sha2-256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
Connection closed by 10.8.0.128 port 22

SSH connection via ETH works normally.

Connection via telnet TUN also works normally.

 

ssh root@192.168.1.54
telnet 10.8.0.128

 

 

 

[gusto]

No SSH port is set in dropbear. I tried to add default port 22

vi /etc/default/dropbear

DROPBEAR_PORT=22

It still won't connect me. This is the log from dropbear

Dec 14 08:55:42 formuler4 authpriv.info dropbear[1112]: Child connection from 10.8.0.104:39340
Dec 14 08:55:42 formuler4 authpriv.info dropbear[1112]: Exit before auth from <10.8.0.104:39340>: Failed assertion (../dropbear-2020.81/rsa.c:164): `key != NULL'

If I try to use another port for SSH

DROPBEAR_PORT=2222

ssh root@10.8.0.128 -p 2222

Then the connection works.

[Dorfkind]

Port 22 already in use, I think. nmap will show you more.

[gusto]

PORT     STATE SERVICE
21/tcp   open  ftp
23/tcp   open  telnet
80/tcp   open  http
111/tcp  open  rpcbind
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
2049/tcp open  nfs
2222/tcp open  EtherNetIP-1
8001/tcp open  vcom-tunnel
8888/tcp open  sun-answerbook

[gusto]

NMAP where SSH does not work

PORT     STATE SERVICE
21/tcp   open  ftp
22/tcp   open  ssh
23/tcp   open  telnet
80/tcp   open  http
111/tcp  open  rpcbind
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
2049/tcp open  nfs
8001/tcp open  vcom-tunnel
8888/tcp open  sun-answerbook

[wian]

I have the same issue. I think it is because dropbear doesn't understand the type of SSH key used for authentication. The dropbear version is pretty old (2020), I've asked them to update it to the 2024.85 version.

[40H3X]

Please read https://forums.openp...zed-keys/page-2 and dropbaer

[WanWizard]

I have the same issue. I think it is because dropbear doesn't understand the type of SSH key used for authentication. The dropbear version is pretty old (2020), I've asked them to update it to the 2024.85 version.

 

Not related, and ed25519, which is most commonly used now, is supported.

 

The problem here is that

debug1: SSH2_MSG_KEX_ECDH_REPLY received

doesn't come when trying to connect through the tunnel.

 

By default dropbear listens on all interfaces:

root@vusolo4k:~# netstat -lnpt | grep dropbear
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1367/dropbear
tcp        0      0 :::22                   :::*                    LISTEN      1367/dropbear

and I have no issue here connecting through an OpenVPN tunnel.
 

It might be related to https://github.com/m...bear/issues/219, but that suggests the TS has been fiddling with that host key, as by default we use "ecdsa-sha2-nistp52nistp521", which doesn't have a problem.

 

But then, is shouldn't work from the LAN either...

[WanWizard]

Dropbear has been upgraded to 2024.84 in develop, will be available in the image after tonights build finishes.

[wian]

Thanks for all the info. I will update to dev once available and troubleshoot further then. 

[maciascoque]

Solution in my case: recreate rsa host key:

mv /etc/dropbear/dropbear_rsa_host_key /etc/dropbear/dropbear_rsa_host_key.bak
dropbearkey -t rsa -f /etc/dropbear/dropbear_rsa_host_key
/etc/init.d/dropbear restart