Sunset SSH Ideas

[mkj]

Welcome!

SunsetSSH is new and I'm looking for fun or strange directions it could be used in. It should fit pretty much anywhere, requiring no dynamic allocation or external parts.

A few quick thoughts:

• Run it inside the Linux kernel. It could give you dmesg output even when userspace has locked up or is paging terribly, it only needs a few tens of kB ram.
• Make it the front-end for a network attached microcontroller music synth
• Turn it into a humane version of Prometheus embedded into your programs, for your pet servers (not cattle). You could SSH into a program and check how it's going.

Any and all suggestions appreciated here! I'll give no promises about possible implementation, but perhaps someone will pick it up.

[gozzarda]

I'll throw in my two cents that a memory safe embedded SSH server is probably one of the safer and more usable ways to poke remote commands into just about any IoT device. The classic solution would be pubsub but the cryptography options out there for embedded pubsub clients are really lacking and expect you to layer your own crypto on top. I don't think I have yet seen a correctly configured cryptographically secured pubsub IoT device, so having a simple and extremely broadly compatible standard like ssh will make secure embedded services much more accessible.

[linuxtim]

A very light "service processor" ("BMC" replacement) seems like a great use-case.

To provide hardware monitoring and remote control, most server (and some workstation) class x86 hardware include a BMC ("Baseboard Management Controller") - either integral to the main board, or as a plug-in module, which is used for hardware monitoring, and remote control.

Over time these have become bloated, and are usually implemented as bunch of closed source software running atop a horrific IoT style Linux on ARM OS. They usually implement some big heavy-weight standards like IPMI and Redfish. Security vulnerabilities are common-place, and many of these implementations are able to operate as PCI bus masters on the "main" server itself and also often have access to the main BIOS chip, and so are an excellent way insert persistent back doors into servers.

The original "service processors" typically provided a way to remotely access a computer via a serial console, and sometimes issue a hard reset or control power.

This functionality could be implemented with a small micro controller based board, which has an external Ethernet interface. Sunset could be used to provide remote access to a UART on the main board (often there is a low voltage UART available on a debug header, or otherwise an RS232 header available). Alternatively it could also connect via USB and provide e.g. CDC-ACM serial virtual UART to the host (although this increases the security cross-section).

GPIO lines could be offer functionality equivalent to pressing a reset or power button. For hosts with firmware ("BIOS") which include "serial redirection" features, you would then essentially have full remote control of the machine.

If desired, more functionality could be implemented over USB (e.g. CDC-ECM or rndis) to provide a low-bandwidth auxiliary management Ethernet port (using SmolTCP bridge features) , or USB storage (the µC could host an SD card, which could be written remotely via sunset, and then "inserted" into the host as a virtual USB storage device).

Power requirements should be low enough that it could draw from a standby voltage supply on the mainboard (usually 5v or 12v) e.g. via an internal USB header.

This would also be useable on non-x86 devices such as Raspberry Pi 5 and other SBCs.

See also Oxide Computer's service processor (this uses their "hubris" rust based RTOS on a STM32H7, but as far as I know doesn't implement an ssh server).