SSH With Embedded Devices
With normal Linux systems using $HOME/.ssh/config eliminates the need for entering an account name and password. Nice. Convenient.
Contrarily, embedded devices are hit and miss. Many embedded devices use the Linux kernel but are not full fledged Linux environments. Instead the operating system is proprietary. Many older embedded devices do not support SSH. Some devices only support SSH passwords and do not support key pairs. Many embedded devices only support a root account and do not support non root accounts.
Of those devices that support SSH in some form, the expect command often will not help to automate tasks because those devices do not use a common Linux shell. Instead a proprietary text based user interface (TUI) is used upon login. The TUI is not necessarily ncurses.
In addition to a TUI, the vendor might use some kind of chroot environment to limit access to the device operating system. Often embedded devices do not use or support bash but rather a limited shell such as ash or busybox. Many embedded devices do not support any kind of Linux user environment and only support certain vendor commands.
When supported, embedded devices often use a limited subset of Linux commands. Scripting needs to be basic and simple with no common expectations found in a common Linux system. If the script is stored on the device, the declaration header needs to be #!/bin/sh rather than #!/bin/bash because likely bash is not installed.
Sometimes the only approach to automating tasks is scripting the actual keystrokes. Useful commands include sshpass and xdotool.
Embedded devices commonly do not have muscle bound hardware and often respond slowly, especially over a network connection. Automating tasks means using the sleep command to pause long enough for emulated keystrokes to complete.
Emulating key strokes with expect or xdotool is much like walking a tight rope. Significant “idiot proofing” is needed so the scripts fail gracefully without disrupting the device function. Much bench testing is needed before pushing into production.
If the device supports interactive access, then a custom shell script might be possible that can be uploaded or copied to the device. If the device is sufficiently proprietary there might not be any place to actually upload or store such scripts because of the limited access.
Posted: Category: Usability Tagged: General
Next: Some Simple Usability Experiments
Previous: LibreOffice Launch Speed