FOR TIPS, gUIDES & TUTORIALS

subscribe to our Youtube

GO TO YOUTUBE

14455 questions

17168 answers

28195 comments

0 members

We are migrating to our new platform at https://community.teltonika.lt. Moving forward, you can continue discussions on this new platform. This current platform will be temporarily maintained for reference purposes.
0 votes
1,058 views 23 comments
by anonymous
Why ssh from a linux device (w/ Dropbear v2014.66) to RUT240 works but not RUT955? The error I got is "ssh: Connection to root@192.168.1.1:22 exited: No matching algo mac c->s". RUT240 and RUT955 both have Dropbear v2019.78 on them. Is there a setting I can change to make it work on the RUT955? It was running RUT9XX_R_00.06.06.1. I upgraded it to the recent factory version RUT9XX_R_00.06.08.6, but still isn't working.

1 Answer

0 votes
by anonymous
Hello,

On the RUT955, copy /etc/dropbear/dropbear_rsa_host_key to /root/.ssh/id_dropbear mode 0600 and try again.

Regads,
Best answer
by anonymous

root@Teltonika-RUT955:~# ls -l .ssh

-rw-------    1 root     root           805 Mar  7  2022 id_dropbear

I still get the same error.

by anonymous

Did you extract the public key of the RUT955 and add it to /etc/dropbear/authorized_keys  on the RUT240 ?

dropbearkey -y -f /etc/dropbear/dropbear_rsa_host_key | grep ssh-rsa

by anonymous
Oh I apologize if I didn't make it clear above. I'm trying to ssh from a linux device (w/ Dropbear v2014.66) to RUT955. The same linux device ssh into RUT240 fine, but it could not ssh into RUT955. The connection is via Lan cable.
by anonymous
Then it is the same, have the correct id_dropbear on the Linux system and a copy of the public key in the RUT955 authorized_keys. Or you can use ssh -i /path/to/dropbear_rsa_host_key root@xxx
by anonymous
I'm trying to mimic the same situation with the RUT240. When I ssh from the linux device to the RUT240 via Lan, it uses a pw for authentication. There are no public or private keys set up.
by anonymous
What is the content of /etc/config/dropbear on both devices ?
by anonymous

root@Teltonika-RUT955:~# cat /etc/config/dropbear 

config dropbear

option PasswordAuth 'on'

option RootPasswordAuth 'on'

option Port '22'

option enable '1'

root@Teltonika-RUT240:~# cat /etc/config/dropbear 

config dropbear

option PasswordAuth 'on'

option RootPasswordAuth 'on'

option enable '1'

option Port '22'

by anonymous

What is the output of

ssh -c help
ssh -m help

on the two RUTs and the Linux device ? 

by anonymous
RUT240 & RUT955 exactly the same:

root@Teltonika-RUT955:~# ssh -c help

Dropbear SSH client v2019.78 https://matt.ucc.asn.au/dropbear/dropbear.html

Usage: ssh [options] [user@]host[/port] [command]

-p <remoteport>

-l <username>

-t    Allocate a pty

-T    Don't allocate a pty

-N    Don't run a remote command

-f    Run in background after auth

-y    Always accept remote host key if unknown

-y -y Don't perform any remote host key checking (caution)

-s    Request a subsystem (use by external sftp)

-o option     Set option in OpenSSH-like format ('-o help' to list options)

-i <identityfile>   (multiple allowed, default .ssh/id_dropbear)

-A    Enable agent auth forwarding

-L <[listenaddress:]listenport:remotehost:remoteport> Local port forwarding

-g    Allow remote hosts to connect to forwarded ports

-R <[listenaddress:]listenport:remotehost:remoteport> Remote port forwarding

-W <receive_window_buffer> (default 24576, larger may be faster, max 1MB)

-K <keepalive>  (0 is never, default 0)

-I <idle_timeout>  (0 is never, default 0)

-J <proxy_program> Use program pipe rather than TCP connection

-c <cipher list> Specify preferred ciphers ('-c help' to list options)

-m <MAC list> Specify preferred MACs for packet verification (or '-m help')

-b    [bind_address][:bind_port]

-V    Version

root@Teltonika-RUT955:~# ssh -m help

Dropbear SSH client v2019.78 https://matt.ucc.asn.au/dropbear/dropbear.html

Usage: ssh [options] [user@]host[/port] [command]

-p <remoteport>

-l <username>

-t    Allocate a pty

-T    Don't allocate a pty

-N    Don't run a remote command

-f    Run in background after auth

-y    Always accept remote host key if unknown

-y -y Don't perform any remote host key checking (caution)

-s    Request a subsystem (use by external sftp)

-o option     Set option in OpenSSH-like format ('-o help' to list options)

-i <identityfile>   (multiple allowed, default .ssh/id_dropbear)

-A    Enable agent auth forwarding

-L <[listenaddress:]listenport:remotehost:remoteport> Local port forwarding

-g    Allow remote hosts to connect to forwarded ports

-R <[listenaddress:]listenport:remotehost:remoteport> Remote port forwarding

-W <receive_window_buffer> (default 24576, larger may be faster, max 1MB)

-K <keepalive>  (0 is never, default 0)

-I <idle_timeout>  (0 is never, default 0)

-J <proxy_program> Use program pipe rather than TCP connection

-c <cipher list> Specify preferred ciphers ('-c help' to list options)

-m <MAC list> Specify preferred MACs for packet verification (or '-m help')

-b    [bind_address][:bind_port]

-V    Version

Linux device:

linux-device:~ $ ssh -c help

ssh: Available ciphers:

aes128-ctr,3des-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes256-cbc,twofish256-cbc,twofish-cbc,twofish128-cbc

ssh: Exited: .

linux-device:~ $ ssh -m help

ssh: Available MACs:

hmac-sha1-96,hmac-sha1,hmac-md5

ssh: Exited: .
by anonymous
Something is strange here ssh -c help and ssh -m help should give the list of ciphers and macs respectively, instead they print a usage message but not the expected data. What is the result without a space between the c/m and help ?
by anonymous
Same results on all of them.
by anonymous

This issue won't be easy to debug without the list of available MACs. As ssh -m help doesn't work you can try strings /usr/sbin/dropbear | grep mac to extract the supported algos.

by anonymous
It returned nothing on all of them.
by anonymous
Last try: ssh -m hmac-sha1 root@RUT955 or ssh -m hmac-sh2-256 root@RUT955.
by anonymous

ssh -m hmac-sha1 gave same error: No matching algo mac c->s

ssh -m hmac-sh2-256 returned "This Dropbear program does not support 'hmac-sh2-256' MAC algorithm"

by anonymous

ssh -m hmac-sha2-256, sorry for the typo.

by anonymous

Same result: "This Dropbear program does not support 'hmac-sha2-256' MAC algorithm"

by anonymous
What is this linux device ? Is it possible to upgrade its dropbear binary with a more recent version ?
by anonymous
Upgrading its dropbear would fix the problem. But I'm looking for other alternatives. The question remains as why does it work on RUT240 but not RUT955?
by anonymous

Because the dropbear on the RUT240 supports at least one algo from (hmac-sha1-96, hmac-sha1, hmac-md5) and the dropbear on the RUT955 doesn't. But they dont say which ones they support ...

Another solution would be to recompile a dropbear for the RUT955 using the SDK.

by anonymous
Should we be trying legacy build or RUTOS, what's the difference, why is one 400MB and the other only 97MB?

Why are we getting tar: Removing leading '/' from member names?

How do we customize the 955 build to add those packages that you mentioned  (hmac-sha1-96, hmac-sha1, hmac-md5)?

Thank you
by anonymous
The legacy version contains pre-downloaded packages the RUTOS version doesn't the difference in size is there. Use the RUTOS version, it should contain the required algos by default, else from make menuconfig go to Base system->Dropbear configuration.
by anonymous
While waiting for it to build I upgraded the RUT955 to RUT9_R_00.07.01.4 because I figure that I would get the same dropbear here. And it worked. Thank you very much for your quick responses and thorough explanations. I appreciate it.