[GSoC 2026] Dropbear port (or other SSH Server/Client) to NuttX

[FelipeMdeO]

Description

Hello everyone,

I would like to volunteer to develop SSH Client/Server support for NuttX. I believe this is a highly valuable feature, as it would enable remote access to NuttX-based hardware in the field for maintenance and operational purposes. With SSH support, we could remotely interact with devices, trigger I/Os, manage peripherals, and perform diagnostics in a way that is conceptually similar to what we already do on Linux-based systems.
Also, this is a great opportunity for me to develop my skills.

The implementation would be based on Dropbear, a lightweight and complete SSH stack with a small footprint, which makes it well-suited for embedded environments. There is already a reference port available that I plan to use as a development guide:
https://github.com/david-cermak/dropbear

The project would be structured in the following phases:

1. Initial study phase to assess requirements and dependencies, including evaluation of cryptographic library integration and system constraints.
2. Review of existing ports for other platforms (for example, ESP-IDF) to understand architectural decisions and integration patterns.
3. Porting of the required SSH client and server functionalities to NuttX.
4. Testing, validation, performance assessment, and resolution of identified issues.

Looking forward to your feedback, tips and suggestions.

Verification

• I have verified before submitting the report.

[michallenc]

@acassis I think this would be nice GSoC project. It would also be worth it to consider Nano SSH server https://github.com/eisbaw/nano_ssh_server, it seems pretty lightweight - though it's only server side, so Dropbear seems like a better option.

[acassis]

@michallenc True, in fact @pbarada suggested nano_ssh_server last week, I never heard about it before. Another alternative is tinyssh: https://github.com/janmojzis/tinyssh

So, I think @FelipeMdeO will need to assess these 3 options and see which one works better, is small enough and secure.

[FelipeMdeO]

Of course. I will add as first step evaluation about these 3 options.

[pbarada]

@acassis I suggested TinySSH. :)
I have (kicking around) a hacked Nuttx tree that includes a TinySSH application that compiles. I hadn't gotten to point of making changes to get it to run (e.g. Nuttx replacement for fork/exec and creating a session, handle keys on backing store, etc). To get it to compile I tweaked source (ifdef'd out code, provided configuration values, etc) to understand its footprint. If you think such would be useful for that part of the project, I'll redo those changes in a new github branch and stage the commits to make it easier to separate/understand the changes I made.
I'd also think it makes sense to want whatever SSH client/server package used to be configurable to include just client or server sides as well as both.

[acassis]

Hi @pbarada yes, I think it could be very useful! Please do it and share the link with your repo here :-)

[pbarada]

I'll have it together in a couple of days...

[linguini1]

I have not heard of TinySSH or NanoSSH, but I have heard of dropbear. I would support any/all of these being implemented for NuttX, I think it's a great idea to have SSH server support specifically.

[FelipeMdeO]

If the @pbarada's implementation is close to be added to NuttX, we can add it and add more one other, or add the 3 current options.

[pbarada]

@acassis Here's the branch: https://github.com/pbarada/nuttx-apps/tree/tinyssh-ref
This is compile/link only so far, and required not only disabling terminal session code but also reducing buffer sizes (which by default are massive and now Kconfig configurable) to make it fit. Haven't tried to launch it (since terminal session code needs to be created that provides equivilent functionality to fork()/execve() - so no idea (yet)whether code handles smaller buffers. See nuttx-apps/netutils/tinyssh/INSTALL for details.

[acassis]

@pbarada thank you @pbarada I think it will be useful anyway!

[pbarada]

@acassis hopefully what's in the branch makes for a decent launching point.
As mentioned in INSTALL file, I wonder whether can use (modified?) /dev/telnet device (much like telnet daemon does) to setup a shell that can be used as part of a replacement for the terminal session code I '#ifdef'd out in channel_exec().