Running dropbear as fallback SSH daemon

← Ansible export facts to simple csv file | posts | Ansible limiting node count on demand →

Most linux distributions default choice SSH daemon is the OpenSSH implementaton. But managing and updating the openssh server results sometimes in connection loss to the target node. A nasty task to solve, especially if there is no out of band management available f.e. : via serial connection or KVM console or power management via PoE. This ends in a visit on site to reset the failed hardware, in good hope the node will survive the reboot, and come up in a manageable state.

This specific kind of management loss can be solved easy by running 2 different SSH daemons on the target node. Both SSH deamons listening on different TCP port. Linux distributions offer sometimes a additional SSH daemon called dropbear. Both SSH implementations OpenSSH and dropbear will run at the same time on the target node. This helps out during occasional updates on the system. By having a separate, redundant SSH installation that is not affected by current SSH server update. It works vice-versa. By updating the dropbear SSH server, the running OpenSSH server is the fallback solution.

The assumption is target node runs OpenSSH server already:

Verify first using the command ss:

user % ss -tulpen | grep ssh

tcp   LISTEN 0      128                              0.0.0.0:22        0.0.0.0:*    users:(("sshd",pid=26925,fd=3)) ino:2884866 sk:5 <->

Install dropbear server:

root # emerge -va dropbear

Configure dropbear to run listening on port 22222, not allowing root login. Display dropbear help to get an overview of available daemon running options:

user % dropbear -h

Edit the /etc/conf.d/dropbear config file, and set -w and -p option:

# see dropbear -h for more information
# -w disables root logins
# -p changes the port number to listen on
DROPBEAR_OPTS="-w -p 0.0.0.0:22222"

Start the dropbear daemon:

root # /etc/init.d/dropbear start

root # service dropbear start

Verify active TCP sockets:

root # ss -tulpen | egrep 'ssh|bear'

tcp   LISTEN 0      0                                    0.0.0.0:22        0.0.0.0:*    users:(("sshd",pid=4322,fd=3)) ino:5231627 sk:12a93723
tcp   LISTEN 0      0                                    0.0.0.0:22222     0.0.0.0:*    users:(("dropbear",pid=2324,fd=4)) ino:5232378 sk:2c1684223

On nodes the entry 0.0.0.0 means, the daemon is listening on all local available IP interfaces. No explicit interfaces given, catchall option.

Test local connectivity and availability by using the dropbear SSH client dbclient:

user % dbclient localhost/22222

user % dbclient localhost

Do the same with OpenSSH SSH client software:

user % ssh localhost -p 222222

user % ssh localhost

If you use PuTTy by any chance then plink is the CLI client software:

user % plink localhost -P 22222

user % plink localhost

This is a solution solving a single point of failure for a node, where no physical management access is given to the target. It solves this specific problem, by adding another, redundant, independent, working SSH daemon.

I used to be an adventurer like you, then I took an arrow in the knee.