Dropbear server support

[XavierChanth]

Is your feature request related to a problem? Please describe.

Use dropbear server in replacement of openssh-server with sshnpd.

Describe the solution you'd like

N/A

Describe alternatives you've considered

No response

Additional context

TCP local forwarding is required to be enabled with dropbear. https://stackoverflow.com/questions/62648290/how-do-i-port-forward-in-dropbear-ssh

[cpswan]

Beware that the kind of environments where we find Dropbear (e.g. it's the default sshd for OpenWRT) are likely to be resource constrained and may also be on instruction set architectures that aren't supported by Dart (or be using libc that can't be used by Dart AOT binaries).

[KunChiLu]

My environment is based on a buildroot arm64 embedded device. Currently, I have copied the sshnoport arm64 Linux binary file into the device, and I can perform preliminary execution as follows: ./sshnpd Version : 4.0.4 -k, --key-file Sending atSign's keyFile if not in ~/.atsign/keys/ -a, --atsign (mandatory) atSign of this device -m, --manager (mandatory) Managers atSign, that this device will accept triggers from -d, --device Send a trigger to this device, allows multiple devices share an atSign (defaults to "default") -s, --[no-]sshpublickey When set, will update authorized_keys to include public key sent by manager -u, --[no-]un-hide When set, makes various information visible to the manager atSign - e.g. usernam e, version, etc -v, --[no-]verbose More logging --ssh-client What to use for outbound ssh connections. [openssh (default), dart] --root-domain atDirectory domain (defaults to "root.atsign.org") --local-sshd-port port on which sshd is listening locally on localhost (defaults to "22") --ephemeral-permissions The permissions which will be added to the authorized_keys file for the ephemera l public keys which are generated when a client is connecting via forward ssh e.g. PermitOpen="host-1:3389",Per mitOpen="localhost:80" (defaults to "") --ssh-algorithm Use RSA 4096 keys rather than the default ED25519 keys [ssh-ed25519 (default), ssh-rsa]

Invalid argument(s): Option atsign is mandatory.

Does this imply that Dart AOT binaries can be executed normally?

[cpswan]

Hi @KunChiLu getting the usage info to print like you have shows that the Dart AOT binary is indeed working :)

This is good news, as it limits the problem at hand to interoperability with Dropbear rather than the range of other issues we've tripped across in other environments.

[cconstab]

DropBear on OpenWRT does not accept the following in the authorized_hosts file

permitopen="localhost:22" ssh-rsa AAAAB3NzaC1yc2EAAAADA..............

It is mentioned in the documentation but when using it the server ignores the Key and prompts for a password.

I do have a version of sshnpd in a docker container that works just fine with a sshd (Openssh) running on the host, but DropBear not supporting the above prevents sshnp working in a secure manner.

moving to sshnpd in a Docker container and moving from Dropbear to Openssh seems to be prudent.

I was testing against Dropbear server v2020.81 https://matt.ucc.asn.au/dropbear/dropbear.html

beta sshnpd (v5.0.2) in a docker container can be found on dockerhub at cconstab/sshnpd-slim

I will continue testing on OpenWRT and provide documentation and prod version of the "slim" sshnpd docker container in the comming days - @cconstab

[cpswan]

@cconstab containers won't be an option on smaller devices.

Can you drop in a link to that documentation that you found please. I think this is one of those things where you've got a full understanding of the issue and its consequences that maybe isn't completely coming through to the rest of us on this thread.

[cconstab]

Moving from Dropbear to Openssh using this as a guide

and running the above mentioned sshnpd in a docker container worked fine..

cconstab@tarial ~ % sshnp -f @cconstab -t @ssh_1 -d openwrt -h @rv_am -i ~/.ssh/GitHub_rsa -u root -s
2024-02-08 06:52:41.281094 : Resolving remote username for user session
2024-02-08 06:52:41.281114 : Resolving remote username for tunnel session
2024-02-08 06:52:41.281368 : Sharing ssh public key
2024-02-08 06:52:41.812657 : Fetching host and port from srvd
2024-02-08 06:52:42.658803 : Sending session request to the device daemon
2024-02-08 06:52:42.756063 : Waiting for response from the device daemon
2024-02-08 06:52:45.034254 : Received response from the device daemon
2024-02-08 06:52:45.034394 : Creating connection to socket rendezvous
2024-02-08 06:52:45.117497 : Starting tunnel session
2024-02-08 06:52:45.848503 : Starting user session

BusyBox v1.33.2 (2022-10-09 13:30:12 UTC) built-in shell (ash)

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt 21.02-SNAPSHOT, r16681+16-830b07f08e
 -----------------------------------------------------
root@OpenWrt:~# 

[cconstab]

https://matt.ucc.asn.au/dropbear/dropbear.html

In this link and then documented in the Github Man page here

https://github.com/mkj/dropbear/blob/master/manpages/dropbear.8

Search for command= which does work on dropbear as is on openwrt permitopen= is also mentioned but does not work on dropbear on openwrt

[cconstab]

@cpswan sorry been working on this waiting for an aircraft which has now arrived. Better/more details to come. I will try building dropbear from source with the above options. My assumption that will work, if not I will raise a issue/PR with the dropbear folks.

[cpswan]

@cconstab bear in mind that Dropbear on OpenWRT is tightly integrated into their UCI config system, so I'd expect the Dropbear maintainers to take a 'not our circus, not our clowns' approach.

[cconstab]

@cpswan .. The original ticket if for dropbear support so I will address that with the dropbear source. OpenWrt I think will have many options available but the slim sshnp container (34mb) is small for most Pi/PC installs and includes ssh and ssh-keygen static binaries. This is way better than the current whole container approach which comes in at 300mb. The C version will pick up the tiny openwrt boxes and other custom hw.

[KunChiLu]

Based on my current experience, with Dropbear 2022.83, you can use permitopen, and ssh-keygen needs to be modified to dropbearkey and dropbearconvert.

In noports-5.0.2: In noports-5.0.2/packages/dart/noports_core/lib/src/common/at_ssh_key_util/local_ssh_key_util.dart, my modifications are as follows:

Change: (line 13) SupportedSshAlgorithm.ed25519: ['-t', 'ed25519', '-a', '100'], to: SupportedSshAlgorithm.ed25519: ['-t', 'ed25519'],

Change: (line112)

await processRunner(
      'ssh-keygen',
      [..._sshKeygenArgMap[algorithm]!, '-f', identifier, '-q', '-N', ''],
      workingDirectory: workingDirectory,
    );

To:

 await processRunner(
      'dropbearkey',
      [..._sshKeygenArgMap[algorithm]!, '-f', identifier, '', '', ''],
      //[..._sshKeygenArgMap[algorithm]!, '-f', identifier, '-q', '-N', ''],
      workingDirectory: workingDirectory,
    );

And add:

await processRunner(
      'dropbearconvert',
      ['dropbear', 'openssh', identifier, identifier],
      workingDirectory: workingDirectory,
    );

Change: (line161)

'command="echo \\"ssh session complete\\";sleep 20"'
        ',PermitOpen="localhost:$localSshdPort"'
        '$permissions'

to:

'command="echo \\"ssh_session_complete\\";sleep 20"'
        ',permitopen="localhost:$localSshdPort"'
        //'$permissions'

This should provide preliminary support for Dropbear.

[KunChiLu]

In my embedded system, I only have 24MB to install the entire Linux system. For me, if an application is larger than 3MB, it can be considered to occupy a significant amount of space. Currently, with the Dart version, sshnpd and srv occupy around 16.7MB of space, which makes it difficult for me to incorporate them into the system.

I'm not sure if reducing the space usage further is possible with the C language version, but I'm hopeful for such a change.

@cconstab containers won't be an option on smaller devices.

[cconstab]

We would be interested to know what TLS libs you are using as we need to use TLS. C will be smaller but depends on what libs we can re use

[KunChiLu]

In my current environment, mbedtls is the default choice, and it is currently under development for TLS 1.3 support. According to the current roadmap, there is a possibility of improved TLS 1.3 support starting from version 3.6. TLS 1.2 is currently available.

[XavierChanth]

In my current environment, mbedtls is the default choice, and it is currently under development for TLS 1.3 support. According to the current roadmap, there is a possibility of improved TLS 1.3 support starting from version 3.6. TLS 1.2 is currently available.

Great news! We are using mbedtls to develop the C version