Aksal/nuttx
3
1
Fork 1
mirror of https://github.com/apache/nuttx.git synced 2026-08-01 20:28:58 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 2

Documentation/esp32c3-devkit: document Dropbear SSH server setup

Browse source 
Describe how to enable and use the Dropbear SSH server on the ESP32-C3
DevKit, including Wi-Fi, host key, and login configuration.

Signed-off-by: Felipe Moura <moura.fmo@gmail.com>
This commit is contained in:
Felipe Moura 2026-06-13 17:26:59 -03:00 • committed by Alan C. Assis
parent e46e7edbdf
commit 3f00e60c1f
1 changed files with 48 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

48
Documentation/platforms/risc-v/esp32c3/boards/esp32c3-devkit/index.rst
View file

@ -211,6 +211,54 @@ should look like this::
hmac sha256 success
hmac sha256 success
dropbear
--------
This configuration brings up the `Dropbear <https://matt.ucc.asn.au/dropbear/dropbear.html>`__
SSH server so that an NSH session can be reached over the network. It pulls in
Wi-Fi station mode, the DHCP client, the WAPI tooling and ``/dev/urandom`` so the
link is configured automatically at boot, and it persists the SSH host key and
the user database on the SPIFFS partition mounted at ``/data``.
The Wi-Fi credentials shipped in the defconfig are placeholders. Set your own
SSID and passphrase before flashing::
$ make menuconfig
-> Application Configuration
-> Network Utilities
-> Network initialization (NETUTILS_NETINIT [=y])
-> WAPI Configuration
When the board boots it joins the configured network, requests an address over
DHCP and starts the Dropbear daemon. Check the assigned address with::
nsh> ifconfig
wlan0 Link encap:Ethernet HWaddr 84:f7:03:xx:xx:xx at RUNNING mtu 1504
inet addr:192.168.1.xx DRaddr:192.168.1.x Mask:255.255.255.0
The first time the daemon runs it generates an ECDSA host key and stores it at
``/data/dropbear_ecdsa_host_key`` (``CONFIG_NETUTILS_DROPBEAR_HOSTKEY_PATH``), and
the user accounts are read from ``/data/passwd`` (``CONFIG_FSUTILS_PASSWD_PATH``).
Because both files live on the persistent ``/data`` partition, the host key and
the credentials survive reboots, so clients do not see a changing host key.
Add a user from the board before connecting (the password file is created on the
first ``useradd``)::
nsh> useradd admin mypassword
From a host on the same network, open an SSH session and run NSH commands
remotely::
$ ssh admin@192.168.1.xx
admin@192.168.1.xx's password:
nsh>
Each session runs over a pseudo-terminal (``CONFIG_PSEUDOTERM``), and ``Ctrl-C``
is forwarded to the remote NSH (``CONFIG_TTY_SIGINT``). The daemon keeps running
after a session ends, so multiple clients can connect over time.
efuse
-----