+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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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čí <[email protected]> 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 <[email protected]> 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 >>> > > > > <[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> >>> > > > >>> > > > >> >> >> >> -- >> Felipe Moura de Oliveira >> Universidade Federal de Minas Gerais >> Linkedin >>
