|
NetBurner 3.5.8
PDF Version |
Example Path: examples/SSH/SshServerUserKey
This NetBurner application demonstrates how to create an SSH server that supports multiple key sources and provides a web-based interface for key management. The application showcases secure SSH connections with user-uploadable keys while maintaining fallback security through default keys.
Additional pdf documentation is located in the example directory
The application uses a three-tier key priority system:
This ensures the device always has a valid key for SSH connections.
This example stores its SSH keys (and other settings) in the on-chip flash file system. How that file system comes to exist differs by platform, and it is the main thing to understand before building. The example makefile already applies the correct settings for each supported platform; you do not normally need to change them by hand.
These modules boot with a system file system already created and mounted by the platform before UserMain() runs. It holds the device configuration, certificates, and the application image. This example does not create a file system on these modules – it uses the existing one (main.cpp skips fs_main() on RT and simply selects drive 0). The SSH keys are written to it:
rsa.key and ecc.key at the root of the file system (drive 0), and/sys/files/usrparam.Because the application image lives in this same file system, formatting is disabled on the RT modules (the serial [4] Format command and the FTP _format command both no-op there).
COMPCODEFLAGS / linker memory reservation and no separate file-system library to link on the SOMRT1061 or MODRT1171 – the EFFS-STD file system is part of the platform. The makefile already excludes the RT modules from those settings; nothing needs to be configured for them.On the MOD5441X, NANO54415, SB800EX (ColdFire) and MODM7AE70, SBE70LC (SAME70) modules there is no system file system. The application reserves a region of flash for an EFFS-STD file system and creates/mounts it itself (main.cpp calls fs_main()). This is where the Memory Configuration matters, and the makefile sets it per platform:
MOD5441X, NANO54415, SB800EX): a COMPCODEFLAGS range caps the application region so the top of flash is reserved for the file system.MODM7AE70, SBE70LC): -cflag C:3 disables application relocation; the file-system region is reserved dynamically.The makefile also links the EFFS-STD library (libStdFFile.a) for these platforms – and, again, excludes it for the RT modules. In short: for any supported platform you do not need to edit COMPCODEFLAGS by hand; the makefile sets the right value for each, and the RT modules need none.
Access the debug menu via serial connection:
[1] - EFFS Read/Write Test[2] - Display Directory[3] - Display TestFile.txt[4] - Format Flash (WARNING: Data loss; disabled on the RT modules)[5] - Display EFFS Space Usage[6] - Display System Time[7] - Reset to Factory Defaultsmain.cpp - Main application thread and system initializationsshuser.cpp/h - SSH authentication and key management functionsweb.cpp - Web server interface for key upload and displaynvsettings.cpp/h - Non-volatile settings managementpermanentkeyrsa.h - Default RSA key compiled into applicationpermanentkeyecc.h - Default ECC key compiled into applicationopenSsh*.key - Example key files for testingindex.html - Key management page: shows the installed RSA/ECC key sources and provides the key upload and reset formsrsakey.html - Displays the active RSA public key for SSH client configurationecckey.html - Displays the active ECC public key for SSH client configurationstyle.css - Self-contained stylesheet for the web pages (plain CSS, no framework or CDN)logo.png - NetBurner logo used in the page headerFileSystemUtils.cpp/h - EFFS-STD file system utilitiesfs_main.cpp/h - File system initializationeffs_time.cpp/h - File timestamps and NTP supportCOMPCODEFLAGS / reservation settings. Does not apply to the RT modules, which use the platform's system file system.The serial interface provides detailed debug information including:
This example demonstrates several NetBurner development concepts: