Telnet deamon is also automatically spawned from NSH init via call to
nsh_telnetstart function if CONFIG_NSH_DISABLE_TELNETSTART option is not
set.
https://github.com/apache/nuttx-apps/blob/master/nshlib/nsh_init.c#L176
It should be easy to replicate this for SSH as well. I would vote to
include this option as well for ssh port to keep it independent on
init.d approach. It's then super easy for the user to configure SSH and
get it running without needing to figure out init.d.
Michal
On 5/14/26 17:12, Tomek CEDRO wrote:
Hello Felipe and thank you for this work, it is much desired and appreciated :-)
Regarding the daemons you can take a look at telnetd or dhcpd (and
other daemons):
https://github.com/apache/nuttx-apps/tree/master/netutils/telnetd
https://github.com/apache/nuttx-apps/tree/master/netutils/dhcpd
Regarding the daemon startup there is a current INIT.D approach and
new upcoming NXINIT. Daemon should also handle system signals for
restart, kill, etc, for manual handling. You should NOT start daemons
from board logic, not these should be entry points in place of nsh,
this is bad and non-portable practice because other boards would not
have this functionality without modification, and no other application
could run concurrently in a standardized way. Here is some detailed
info on NuttX initialization:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629500#NuttXInitializationSequence-nsh_initialize()
The INIT.D approach is similar to any Unix like systems where shell
scripts from /etc/init.d/ are executed on system start. Please stick
to this solution for now. Here is an example:
https://github.com/apache/nuttx/tree/master/boards/sim/sim/sim/src/etc/init.d
NXINIT is a work in progress and would provide more granular control
over system services, but I am not sure if it is already usable and/or
documented? This can be next step after INIT.D approach is working :-)
There are two more things to consider with SSHD:
1. You need to be ready to support both FLAT and PROTECTED builds, see
https://nuttx.apache.org/docs/latest/guides/protected_build.html.
2. There are many different ways to implement sshd from system,
crypto, libraries, and signals point of view. That would impact
efficiency, complexity, and code size. Dropbear may be good reference
starting point with measurable results. But looking at ssh related
proposals for GSoC this year there were some really nice ideas on how
things can be improved in specific places. Please take a look at them
maybe these will inspire you in some areas when in pinch :-)
Thank you and have fun! :-)
Tomek
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
On Thu, May 14, 2026 at 1:22 PM Felipe Moura Oliveira
<[email protected]> wrote:
Hi all,
I am working on a preliminary Dropbear server port for NuttX and would like
to confirm the expected integration approach before moving further.
As a starting point, I followed David’s ESP-IDF-based steps and, after some
adjustments, I was able to get Dropbear running on an ESP32-C3. I then
started porting it to NuttX.
For the initial proof of concept, I placed the Dropbear server code under
apps/netutils and kept the integration as simple as possible. With this
approach, I was able to get it working.
Before improving the port, I would like to confirm whether this is the
correct location for the Dropbear source code, or if there is a more
appropriate place in the NuttX apps tree.
I also have a question about service initialization. Currently, I need to
manually start the Dropbear application. My expectation is that the SSH
server should be started automatically when enabled in the configuration.
However, as far as I understand, there is no generic apps autostart
mechanism that works across all boards. The alternative would be to add
board-specific startup logic in each board bring-up code, but I would
prefer to avoid that if possible.
What would be the recommended approach for initializing this kind of
network service in NuttX? Should this be handled by board bring-up logic,
NSH initialization, an application-level startup mechanism, or some other
pattern?
Any guidance on the preferred architecture would be appreciated before I
continue refining the port.
--
*Felipe Moura de Oliveira*
*Universidade Federal de Minas Gerais*
Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0>
<https://twitter.com/FelipeMOliveir?lang=pt-br>
