Dropbear SSH port to NuttX

[Felipe Moura Oliveira <mo...@gmail.com>]

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>

Re: Dropbear SSH port to NuttX

["Alan C. Assis" <ac...@gmail.com>]

Hi Matteo and Michal,

I think what we need is something that has the same easy way to use as
Michal noticed, but at the same time doesn't add NSH as a requirement.

I think the NXInit will help to fix this issue.

BR,

Alan

On Thu, May 14, 2026 at 2:43 PM Matteo Golin <ma...@gmail.com> wrote:

> Personally I think we should just do init.d. NSH should really stop being
> the de-facto do-all program and just be a shell.
>
> On Thu, May 14, 2026, 7:10 PM Michal Lenc <mi...@seznam.cz> wrote:
>
> > 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
> > > <mo...@gmail.com> 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>
> >
> >
>

Re: Dropbear SSH port to NuttX

[Felipe Moura Oliveira <mo...@gmail.com>]

Hello All,

Alan, Looking at the Dropbear repository, it still appears to be active:
https://github.com/mkj/dropbear. A new version was released a few days ago.
Therefore, I will implement a build-time solution that fetches a specific
commit SHA. This SHA could be configurable through Kconfig.

I will use Telnet and init.d as reference cases while we decide on the best
integration approach.

Em qui., 14 de mai. de 2026 às 14:43, Matteo Golin <ma...@gmail.com>
escreveu:

> Personally I think we should just do init.d. NSH should really stop being
> the de-facto do-all program and just be a shell.
>
> On Thu, May 14, 2026, 7:10 PM Michal Lenc <mi...@seznam.cz> wrote:
>
> > 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
> > > <mo...@gmail.com> 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>
> >
> >
>


-- 
*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>

Sv: Dropbear SSH port to NuttX

["Alin.Jerpelea@sony.com" <Al...@sony.com>]

+1

Best regards
Alin
________________________________
Från: Tomek CEDRO <to...@cedro.info>
Skickat: den 18 maj 2026 03:29
Till: dev@nuttx.apache.org <de...@nuttx.apache.org>
Ämne: Re: Dropbear SSH port to NuttX

+1 for NuttX crypto where possible :-) -- CeDeROM, SQ7MHZ, https: //urldefense. com/v3/__http: //www. tomek. cedro. info__;!!O7_YSHcmd9jp3hj_4dEAcyQ!wTdi6A9wUM1NGF_ZjkMS2jzAfIxa7CWZTOx2_AvzhizAwjm-ud5c7a_gQsmXb29p0-D_lF-0O6Kl4fVR2Q$ -- CeDeROM, SQ7MHZ,


+1 for NuttX crypto where possible :-)

--
CeDeROM, SQ7MHZ, https://urldefense.com/v3/__http://www.tomek.cedro.info__;!!O7_YSHcmd9jp3hj_4dEAcyQ!wTdi6A9wUM1NGF_ZjkMS2jzAfIxa7CWZTOx2_AvzhizAwjm-ud5c7a_gQsmXb29p0-D_lF-0O6Kl4fVR2Q$

--
CeDeROM, SQ7MHZ, https://urldefense.com/v3/__http://www.tomek.cedro.info__;!!O7_YSHcmd9jp3hj_4dEAcyQ!wTdi6A9wUM1NGF_ZjkMS2jzAfIxa7CWZTOx2_AvzhizAwjm-ud5c7a_gQsmXb29p0-D_lF-0O6Kl4fVR2Q$


On Sun, May 17, 2026 at 5:26 PM Matteo Golin <ma...@gmail.com> wrote:
>
> My guess would be that it's best to use the NuttX crypto libs (smaller binary when users are doing other cryptographic stuff at the same time, and self contained).
>
> Let's see what others have to say.
>
> Matteo
>
> On Sun, May 17, 2026, 1:00 PM Felipe Moura Oliveira <mo...@gmail.com> wrote:
>>
>> Hello everyone,
>>
>> First of all, thank you for your opinions.
>>
>> Right now I'm using the same approach as telnet, mainly because it's a similar example and makes this initial part practical. Later we'll discuss the startup again; we can include a separate task to test what Karel suggested.
>>
>> Regarding Dropbear, I managed to do the basics, but I have doubts about password authentication.
>> The Dropbear repository itself has files with password verification capabilities. See below.
>>
>> Should the Dropbear port:
>>
>> 1.Use Dropbear’s bundled libtomcrypt/libtommath for all Dropbear-related crypto, including this password hash support, keeping the port self-contained and close to upstream Dropbear?
>>
>> or
>>
>> 2. Avoid using bundled crypto for port-specific code and use NuttX crypto APIs instead, even if that means depending on CONFIG_CRYPTO or another NuttX crypto facility?
>>
>>
>>
>> Em sex., 15 de mai. de 2026 às 04:30, Tomek CEDRO <to...@cedro.info> escreveu:
>>>
>>> Ha! That is really nice idea to have nsh also started as service along
>>> other services! That would help in hiding behind a trigger nsh even on
>>> production devices etc :-)
>>>
>>> --
>>> CeDeROM, SQ7MHZ, https://urldefense.com/v3/__http://www.tomek.cedro.info__;!!O7_YSHcmd9jp3hj_4dEAcyQ!wTdi6A9wUM1NGF_ZjkMS2jzAfIxa7CWZTOx2_AvzhizAwjm-ud5c7a_gQsmXb29p0-D_lF-0O6Kl4fVR2Q$
>>>
>>> On Fri, May 15, 2026 at 9:17 AM Karel Kočí <cy...@email.cz> wrote:
>>> >
>>> > I would add that this would be the best option, in my opinion. Having init
>>> > application that can start services, that can include nsh in the end as well. It
>>> > would be also beneficial if it could monitor their status in some minimal way
>>> > and trigger possibly some optional fail safe (such as reset).
>>> >
>>> > But on the other hand that is another work to do. What Michal suggests is to do,
>>> > for now, exactly what we do with telnet. Then we can both migrate to the new
>>> > init, once we implement it. Making these steps virtually independent thanks to
>>> > the precedence established by telnetd.
>>> >
>>> > My two cents..
>>> > Karel
>>> >
>>> >
>>> > On Thu 14 May 2026 07:42:57 PM , Matteo Golin wrote:
>>> > > Personally I think we should just do init.d. NSH should really stop being
>>> > > the de-facto do-all program and just be a shell.
>>> > >
>>> > > On Thu, May 14, 2026, 7:10 PM Michal Lenc <mi...@seznam.cz> wrote:
>>> > >
>>> > > > 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://urldefense.com/v3/__https://github.com/apache/nuttx-apps/blob/master/nshlib/nsh_init.c*L176__;Iw!!O7_YSHcmd9jp3hj_4dEAcyQ!wTdi6A9wUM1NGF_ZjkMS2jzAfIxa7CWZTOx2_AvzhizAwjm-ud5c7a_gQsmXb29p0-D_lF-0O6IM1nRD_w$
>>> > > >
>>> > > > 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://urldefense.com/v3/__https://github.com/apache/nuttx-apps/tree/master/netutils/telnetd__;!!O7_YSHcmd9jp3hj_4dEAcyQ!wTdi6A9wUM1NGF_ZjkMS2jzAfIxa7CWZTOx2_AvzhizAwjm-ud5c7a_gQsmXb29p0-D_lF-0O6JQqT-B1Q$
>>> > > > > https://urldefense.com/v3/__https://github.com/apache/nuttx-apps/tree/master/netutils/dhcpd__;!!O7_YSHcmd9jp3hj_4dEAcyQ!wTdi6A9wUM1NGF_ZjkMS2jzAfIxa7CWZTOx2_AvzhizAwjm-ud5c7a_gQsmXb29p0-D_lF-0O6L-6LEyRw$
>>> > > > >
>>> > > > > 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://urldefense.com/v3/__https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629500*NuttXInitializationSequence-nsh_initialize()__;Iw!!O7_YSHcmd9jp3hj_4dEAcyQ!wTdi6A9wUM1NGF_ZjkMS2jzAfIxa7CWZTOx2_AvzhizAwjm-ud5c7a_gQsmXb29p0-D_lF-0O6Lm3F7Mcg$
>>> > > > >
>>> > > > > 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://urldefense.com/v3/__https://github.com/apache/nuttx/tree/master/boards/sim/sim/sim/src/etc/init.d__;!!O7_YSHcmd9jp3hj_4dEAcyQ!wTdi6A9wUM1NGF_ZjkMS2jzAfIxa7CWZTOx2_AvzhizAwjm-ud5c7a_gQsmXb29p0-D_lF-0O6KHUFBflQ$
>>> > > > >
>>> > > > > 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://urldefense.com/v3/__https://nuttx.apache.org/docs/latest/guides/protected_build.html__;!!O7_YSHcmd9jp3hj_4dEAcyQ!wTdi6A9wUM1NGF_ZjkMS2jzAfIxa7CWZTOx2_AvzhizAwjm-ud5c7a_gQsmXb29p0-D_lF-0O6KzXxQRrQ$.
>>> > > > >
>>> > > > > 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, https://urldefense.com/v3/__http://www.tomek.cedro.info__;!!O7_YSHcmd9jp3hj_4dEAcyQ!wTdi6A9wUM1NGF_ZjkMS2jzAfIxa7CWZTOx2_AvzhizAwjm-ud5c7a_gQsmXb29p0-D_lF-0O6Kl4fVR2Q$
>>> > > > >
>>> > > > > On Thu, May 14, 2026 at 1:22 PM Felipe Moura Oliveira
>>> > > > > <mo...@gmail.com> 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://urldefense.com/v3/__https://www.linkedin.com/in/felipe-oliveira-75a651a0__;!!O7_YSHcmd9jp3hj_4dEAcyQ!wTdi6A9wUM1NGF_ZjkMS2jzAfIxa7CWZTOx2_AvzhizAwjm-ud5c7a_gQsmXb29p0-D_lF-0O6JIaP4zdQ$>
>>> > > > >> <https://urldefense.com/v3/__https://twitter.com/FelipeMOliveir?lang=pt-br__;!!O7_YSHcmd9jp3hj_4dEAcyQ!wTdi6A9wUM1NGF_ZjkMS2jzAfIxa7CWZTOx2_AvzhizAwjm-ud5c7a_gQsmXb29p0-D_lF-0O6I7m-kJ7Q$>
>>> > > >
>>> > > >
>>
>>
>>
>> --
>> Felipe Moura de Oliveira
>> Universidade Federal de Minas Gerais
>> Linkedin
>>

Re: Dropbear SSH port to NuttX

[Tomek CEDRO <to...@cedro.info>]

+1 for NuttX crypto where possible :-)

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info


On Sun, May 17, 2026 at 5:26 PM Matteo Golin <ma...@gmail.com> wrote:
>
> My guess would be that it's best to use the NuttX crypto libs (smaller binary when users are doing other cryptographic stuff at the same time, and self contained).
>
> Let's see what others have to say.
>
> Matteo
>
> On Sun, May 17, 2026, 1:00 PM Felipe Moura Oliveira <mo...@gmail.com> wrote:
>>
>> Hello everyone,
>>
>> First of all, thank you for your opinions.
>>
>> Right now I'm using the same approach as telnet, mainly because it's a similar example and makes this initial part practical. Later we'll discuss the startup again; we can include a separate task to test what Karel suggested.
>>
>> Regarding Dropbear, I managed to do the basics, but I have doubts about password authentication.
>> The Dropbear repository itself has files with password verification capabilities. See below.
>>
>> Should the Dropbear port:
>>
>> 1.Use Dropbear’s bundled libtomcrypt/libtommath for all Dropbear-related crypto, including this password hash support, keeping the port self-contained and close to upstream Dropbear?
>>
>> or
>>
>> 2. Avoid using bundled crypto for port-specific code and use NuttX crypto APIs instead, even if that means depending on CONFIG_CRYPTO or another NuttX crypto facility?
>>
>>
>>
>> Em sex., 15 de mai. de 2026 às 04:30, Tomek CEDRO <to...@cedro.info> escreveu:
>>>
>>> Ha! That is really nice idea to have nsh also started as service along
>>> other services! That would help in hiding behind a trigger nsh even on
>>> production devices etc :-)
>>>
>>> --
>>> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>>>
>>> On Fri, May 15, 2026 at 9:17 AM Karel Kočí <cy...@email.cz> wrote:
>>> >
>>> > I would add that this would be the best option, in my opinion. Having init
>>> > application that can start services, that can include nsh in the end as well. It
>>> > would be also beneficial if it could monitor their status in some minimal way
>>> > and trigger possibly some optional fail safe (such as reset).
>>> >
>>> > But on the other hand that is another work to do. What Michal suggests is to do,
>>> > for now, exactly what we do with telnet. Then we can both migrate to the new
>>> > init, once we implement it. Making these steps virtually independent thanks to
>>> > the precedence established by telnetd.
>>> >
>>> > My two cents..
>>> > Karel
>>> >
>>> >
>>> > On Thu 14 May 2026 07:42:57 PM , Matteo Golin wrote:
>>> > > Personally I think we should just do init.d. NSH should really stop being
>>> > > the de-facto do-all program and just be a shell.
>>> > >
>>> > > On Thu, May 14, 2026, 7:10 PM Michal Lenc <mi...@seznam.cz> wrote:
>>> > >
>>> > > > 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
>>> > > > > <mo...@gmail.com> 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>
>>> > > >
>>> > > >
>>
>>
>>
>> --
>> Felipe Moura de Oliveira
>> Universidade Federal de Minas Gerais
>> Linkedin
>>

Re: Dropbear SSH port to NuttX

[Matteo Golin <ma...@gmail.com>]

My guess would be that it's best to use the NuttX crypto libs (smaller
binary when users are doing other cryptographic stuff at the same time, and
self contained).

Let's see what others have to say.

Matteo

On Sun, May 17, 2026, 1:00 PM Felipe Moura Oliveira <mo...@gmail.com>
wrote:

> Hello everyone,
>
> First of all, thank you for your opinions.
>
> Right now I'm using the same approach as telnet, mainly because it's a
> similar example and makes this initial part practical. Later we'll discuss
> the startup again; we can include a separate task to test what Karel
> suggested.
>
> Regarding Dropbear, I managed to do the basics, *but I have doubts about
> password authentication*.
> The Dropbear repository itself has files with password verification
> capabilities. See below.
> [image: image.png]
>
> Should the Dropbear port:
>
> 1.Use Dropbear’s bundled libtomcrypt/libtommath for all Dropbear-related
> crypto, including this password hash support, keeping the port
> self-contained and close to upstream Dropbear?
>
> *or*
>
> 2. Avoid using bundled crypto for port-specific code and use NuttX crypto
> APIs instead, even if that means depending on CONFIG_CRYPTO or another
> NuttX crypto facility?
>
>
> Em sex., 15 de mai. de 2026 às 04:30, Tomek CEDRO <to...@cedro.info>
> escreveu:
>
>> Ha! That is really nice idea to have nsh also started as service along
>> other services! That would help in hiding behind a trigger nsh even on
>> production devices etc :-)
>>
>> --
>> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>>
>> On Fri, May 15, 2026 at 9:17 AM Karel Kočí <cy...@email.cz> wrote:
>> >
>> > I would add that this would be the best option, in my opinion. Having
>> init
>> > application that can start services, that can include nsh in the end as
>> well. It
>> > would be also beneficial if it could monitor their status in some
>> minimal way
>> > and trigger possibly some optional fail safe (such as reset).
>> >
>> > But on the other hand that is another work to do. What Michal suggests
>> is to do,
>> > for now, exactly what we do with telnet. Then we can both migrate to
>> the new
>> > init, once we implement it. Making these steps virtually independent
>> thanks to
>> > the precedence established by telnetd.
>> >
>> > My two cents..
>> > Karel
>> >
>> >
>> > On Thu 14 May 2026 07:42:57 PM , Matteo Golin wrote:
>> > > Personally I think we should just do init.d. NSH should really stop
>> being
>> > > the de-facto do-all program and just be a shell.
>> > >
>> > > On Thu, May 14, 2026, 7:10 PM Michal Lenc <mi...@seznam.cz>
>> wrote:
>> > >
>> > > > 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
>> > > > > <mo...@gmail.com> 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>
>> > > >
>> > > >
>>
>
>
> --
> *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>
>

Re: Dropbear SSH port to NuttX

[Felipe Moura Oliveira <mo...@gmail.com>]

Hello everyone,

First of all, thank you for your opinions.

Right now I'm using the same approach as telnet, mainly because it's a
similar example and makes this initial part practical. Later we'll discuss
the startup again; we can include a separate task to test what Karel
suggested.

Regarding Dropbear, I managed to do the basics, *but I have doubts about
password authentication*.
The Dropbear repository itself has files with password verification
capabilities. See below.
[image: image.png]

Should the Dropbear port:

1.Use Dropbear’s bundled libtomcrypt/libtommath for all Dropbear-related
crypto, including this password hash support, keeping the port
self-contained and close to upstream Dropbear?

*or*

2. Avoid using bundled crypto for port-specific code and use NuttX crypto
APIs instead, even if that means depending on CONFIG_CRYPTO or another
NuttX crypto facility?


Em sex., 15 de mai. de 2026 às 04:30, Tomek CEDRO <to...@cedro.info>
escreveu:

> Ha! That is really nice idea to have nsh also started as service along
> other services! That would help in hiding behind a trigger nsh even on
> production devices etc :-)
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>
> On Fri, May 15, 2026 at 9:17 AM Karel Kočí <cy...@email.cz> wrote:
> >
> > I would add that this would be the best option, in my opinion. Having
> init
> > application that can start services, that can include nsh in the end as
> well. It
> > would be also beneficial if it could monitor their status in some
> minimal way
> > and trigger possibly some optional fail safe (such as reset).
> >
> > But on the other hand that is another work to do. What Michal suggests
> is to do,
> > for now, exactly what we do with telnet. Then we can both migrate to the
> new
> > init, once we implement it. Making these steps virtually independent
> thanks to
> > the precedence established by telnetd.
> >
> > My two cents..
> > Karel
> >
> >
> > On Thu 14 May 2026 07:42:57 PM , Matteo Golin wrote:
> > > Personally I think we should just do init.d. NSH should really stop
> being
> > > the de-facto do-all program and just be a shell.
> > >
> > > On Thu, May 14, 2026, 7:10 PM Michal Lenc <mi...@seznam.cz>
> wrote:
> > >
> > > > 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
> > > > > <mo...@gmail.com> 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>
> > > >
> > > >
>


-- 
*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>

Re: Dropbear SSH port to NuttX

[Tomek CEDRO <to...@cedro.info>]

Ha! That is really nice idea to have nsh also started as service along
other services! That would help in hiding behind a trigger nsh even on
production devices etc :-)

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

On Fri, May 15, 2026 at 9:17 AM Karel Kočí <cy...@email.cz> wrote:
>
> I would add that this would be the best option, in my opinion. Having init
> application that can start services, that can include nsh in the end as well. It
> would be also beneficial if it could monitor their status in some minimal way
> and trigger possibly some optional fail safe (such as reset).
>
> But on the other hand that is another work to do. What Michal suggests is to do,
> for now, exactly what we do with telnet. Then we can both migrate to the new
> init, once we implement it. Making these steps virtually independent thanks to
> the precedence established by telnetd.
>
> My two cents..
> Karel
>
>
> On Thu 14 May 2026 07:42:57 PM , Matteo Golin wrote:
> > Personally I think we should just do init.d. NSH should really stop being
> > the de-facto do-all program and just be a shell.
> >
> > On Thu, May 14, 2026, 7:10 PM Michal Lenc <mi...@seznam.cz> wrote:
> >
> > > 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
> > > > <mo...@gmail.com> 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>
> > >
> > >

Re: Dropbear SSH port to NuttX

[Karel Kočí <cy...@email.cz>]

I would add that this would be the best option, in my opinion. Having init
application that can start services, that can include nsh in the end as well. It
would be also beneficial if it could monitor their status in some minimal way
and trigger possibly some optional fail safe (such as reset).

But on the other hand that is another work to do. What Michal suggests is to do,
for now, exactly what we do with telnet. Then we can both migrate to the new
init, once we implement it. Making these steps virtually independent thanks to
the precedence established by telnetd.

My two cents..
Karel


On Thu 14 May 2026 07:42:57 PM , Matteo Golin wrote:
> Personally I think we should just do init.d. NSH should really stop being
> the de-facto do-all program and just be a shell.
> 
> On Thu, May 14, 2026, 7:10 PM Michal Lenc <mi...@seznam.cz> wrote:
> 
> > 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
> > > <mo...@gmail.com> 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>
> >
> >

Re: Dropbear SSH port to NuttX

[Matteo Golin <ma...@gmail.com>]

Personally I think we should just do init.d. NSH should really stop being
the de-facto do-all program and just be a shell.

On Thu, May 14, 2026, 7:10 PM Michal Lenc <mi...@seznam.cz> wrote:

> 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
> > <mo...@gmail.com> 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>
>
>

Re: Dropbear SSH port to NuttX

[Michal Lenc <mi...@seznam.cz>]

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
> <mo...@gmail.com> 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>

Re: Dropbear SSH port to NuttX

[Tomek CEDRO <to...@cedro.info>]

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
<mo...@gmail.com> 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>

Re: Dropbear SSH port to NuttX

[Michal Lenc <mi...@seznam.cz>]

> Building on what Alan said, with actively maintained projects, the build
> can fetch either release tarballs or a specific git hash.

I agree this is the best approach. It may also be beneficial to allow 
the user to change the specific hash or release based on Kconfig option.

Michal

On 5/14/26 15:55, Nathan Hartman wrote:
> Building on what Alan said, with actively maintained projects, the build
> can fetch either release tarballs or a specific git hash. If we (NuttX)
> need to apply any patches, we keep those in our repo and apply them at
> build time.
>
> A good example you can look at is our Python port:
> https://github.com/apache/nuttx-apps/tree/master/interpreters/python
>
> There are other examples in the apps tree. Just look around for anything
> with patches. :-)
>
>
> On Thu, May 14, 2026 at 9:48 AM Alan C. Assis <ac...@gmail.com> wrote:
>
>> Hi Felipe,
>>
>> Thank you very much for that great news!
>>
>> I will suggest you what was the Greg's approach for previous projects
>> included inside NuttX Apps:
>>
>> If the project is actively maintained, then you shouldn't include the
>> source code inside nuttx-apps/
>>
>> But if the project is mostly a dead project: a project that hasn't been
>> actively maintained for many years (i.e. 3 or more), then it is fine to
>> include the source code there.
>>
>> BR,
>>
>> Alan
>>
>> On Thu, May 14, 2026 at 10:22 AM Felipe Moura Oliveira <
>> moura.fmo@gmail.com>
>> 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>
>>>

Re: Dropbear SSH port to NuttX

[Nathan Hartman <ha...@gmail.com>]

Building on what Alan said, with actively maintained projects, the build
can fetch either release tarballs or a specific git hash. If we (NuttX)
need to apply any patches, we keep those in our repo and apply them at
build time.

A good example you can look at is our Python port:
https://github.com/apache/nuttx-apps/tree/master/interpreters/python

There are other examples in the apps tree. Just look around for anything
with patches. :-)


On Thu, May 14, 2026 at 9:48 AM Alan C. Assis <ac...@gmail.com> wrote:

> Hi Felipe,
>
> Thank you very much for that great news!
>
> I will suggest you what was the Greg's approach for previous projects
> included inside NuttX Apps:
>
> If the project is actively maintained, then you shouldn't include the
> source code inside nuttx-apps/
>
> But if the project is mostly a dead project: a project that hasn't been
> actively maintained for many years (i.e. 3 or more), then it is fine to
> include the source code there.
>
> BR,
>
> Alan
>
> On Thu, May 14, 2026 at 10:22 AM Felipe Moura Oliveira <
> moura.fmo@gmail.com>
> 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>
> >
>

Re: Dropbear SSH port to NuttX

["Alan C. Assis" <ac...@gmail.com>]

I think telnetd is a good example of how a service should be initialized.

I think we should include NXInit before the NuttX 13.0 window closes.

BR,

BR,

Alan

On Thu, May 14, 2026 at 10:53 AM Matteo Golin <ma...@gmail.com>
wrote:

> An SSH server shouldn't be started in the board bring up code/kernel logic.
> I think it's possible to use an etc/initrc script, but you're right there's
> not really a way that I know of otherwise (we need that NXinit!). Just
> definitely do not start applications from kernel logic.
>
> On Thu, May 14, 2026, 3:48 PM Alan C. Assis <ac...@gmail.com> wrote:
>
> > Hi Felipe,
> >
> > Thank you very much for that great news!
> >
> > I will suggest you what was the Greg's approach for previous projects
> > included inside NuttX Apps:
> >
> > If the project is actively maintained, then you shouldn't include the
> > source code inside nuttx-apps/
> >
> > But if the project is mostly a dead project: a project that hasn't been
> > actively maintained for many years (i.e. 3 or more), then it is fine to
> > include the source code there.
> >
> > BR,
> >
> > Alan
> >
> > On Thu, May 14, 2026 at 10:22 AM Felipe Moura Oliveira <
> > moura.fmo@gmail.com>
> > 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>
> > >
> >
>

Re: Dropbear SSH port to NuttX

[Matteo Golin <ma...@gmail.com>]

An SSH server shouldn't be started in the board bring up code/kernel logic.
I think it's possible to use an etc/initrc script, but you're right there's
not really a way that I know of otherwise (we need that NXinit!). Just
definitely do not start applications from kernel logic.

On Thu, May 14, 2026, 3:48 PM Alan C. Assis <ac...@gmail.com> wrote:

> Hi Felipe,
>
> Thank you very much for that great news!
>
> I will suggest you what was the Greg's approach for previous projects
> included inside NuttX Apps:
>
> If the project is actively maintained, then you shouldn't include the
> source code inside nuttx-apps/
>
> But if the project is mostly a dead project: a project that hasn't been
> actively maintained for many years (i.e. 3 or more), then it is fine to
> include the source code there.
>
> BR,
>
> Alan
>
> On Thu, May 14, 2026 at 10:22 AM Felipe Moura Oliveira <
> moura.fmo@gmail.com>
> 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>
> >
>

Re: Dropbear SSH port to NuttX

["Alan C. Assis" <ac...@gmail.com>]

Hi Felipe,

Thank you very much for that great news!

I will suggest you what was the Greg's approach for previous projects
included inside NuttX Apps:

If the project is actively maintained, then you shouldn't include the
source code inside nuttx-apps/

But if the project is mostly a dead project: a project that hasn't been
actively maintained for many years (i.e. 3 or more), then it is fine to
include the source code there.

BR,

Alan

On Thu, May 14, 2026 at 10:22 AM Felipe Moura Oliveira <mo...@gmail.com>
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>
>