This sample manages local accounts on OpenWrt routers and embedded
devices over SSH. OpenWrt ships a dropbear
SSH server and a BusyBox ash shell, so the login flow, passwd
prompts, and authorized-key store all differ from a standard OpenSSH/bash host. It supports
password check/change and the full SSH authorized-key lifecycle for the managed account.
Platform Script: OpenWrtSsh.json
An OpenWrt host (tested against OpenWrt 25.12.x) reachable over SSH with root login enabled
(config dropbear option RootPasswordAuth 'on'). The managed account is typically root,
the single privileged local account, but non-root local accounts are also supported for SSH-key
operations (their keys resolve to ~/.ssh/authorized_keys).
| Operation | Description |
|---|---|
CheckSystem |
Verifies the service account can log in and read /etc/shadow. |
CheckPassword |
Validates a managed-account password against its /etc/shadow hash. |
ChangePassword |
Changes the managed-account password with BusyBox interactive passwd. |
CheckSshKey |
Reports whether OldSshKey is installed in the account's authorized-keys file. |
ChangeSshKey |
Installs NewSshKey, optionally tests NewSshPrivateKey, then removes OldSshKey. |
DiscoverAuthorizedKeys |
Reads the account's authorized-keys file and emits discovered SSH keys. |
DiscoverSshHostKey |
Retrieves the SSH host key for the target asset. |
This script is derived from generic-linux-ssh-keys with the
following adaptations:
- No
sudo. OpenWrt has nosudoby default and the managed account isroot, so theDelegationPrefixparameter defaults to empty and every reference uses the null-safe form%DelegationPrefix::$%(a bare%DelegationPrefix%throwsVariableIsNullExceptionwhen the value is empty/null). - BusyBox
passwdprompts. RunningpasswdasrootpromptsNew password:thenRetype password:(notRetype new password:) and never asks for the current password. TheChangeUserPasswordsend/receive sequence matches these prompts. - dropbear authorized-keys path. dropbear has no
sshd -T -Cto probe, soDiscoverSshKeyConfigurationselects the path by account:root(uid 0) uses/etc/dropbear/authorized_keys(file mode600, directory mode700); any other account uses the standard~/.ssh/authorized_keys, resolved from%hagainst the account's home directory just like the OpenSSH base sample. grep -Eis used in place of GNUegrep, andsttyis not present on BusyBox (the shell-initstty -echois best-effort and its absence is harmless).
- An OpenWrt host reachable over SSH with root password authentication enabled
- A service account (
root) that can read/etc/shadowand write each managed account's authorized-keys file - For key operations:
rootkeys live in/etc/dropbear/authorized_keys; non-root accounts use~/.ssh/authorized_keys
- Upload the script:
Import-SafeguardCustomPlatformScript -FilePath ./OpenWrtSsh.json - Create a custom platform using this script
- Create an asset using the platform (accept the SSH host key)
- Configure the service account and managed account (
root) - Test with
Test-SafeguardAssetAccountPassword -ExtendedLogging
OldSshKey— Existing public key to verify or removeNewSshKey— New public key to installNewSshPrivateKey— Optional private key used to test the newly installed public keyDelegationPrefix— Privilege-elevation command; defaults to empty on OpenWrtUserKey— Optional SSH private key for the service-account login
- Resolves
rootkeys to/etc/dropbear/authorized_keysand non-root keys to~/.ssh/authorized_keys; does not parse OpenSSHAuthorizedKeysFiledirectives from a config file (dropbear exposes none) - Does not implement a standalone
RemoveAuthorizedKeyoperation - Key parsing is limited to the key types handled in
ParseKey - Assumes the managed account can read
/etc/shadowdirectly (root, no delegation)
- SSH Key Management Guide
- SSH Platforms Guide
- generic-linux-ssh-keys — the OpenSSH/bash base this sample adapts
- SPP Compatibility Matrix