Dropbear configuration

The SSH configuration is handled by the Dropbear subsystem of uci and the configuration file is located in /etc/config/dropbear.

Each dropbear SSH server instance uses a single section of the configuration file, and you can have multiple instances.

The dropbear configuration contains settings for the dropbear SSH server in a single section.

The dropbear section contains these settings. Names are case-sensitive.

Name Type Required Default Description
enable boolean no 1 Set to 0 to disable starting dropbear at system boot.
verbose boolean no 0 Set to 1 to enable verbose output by the start script.
BannerFile string no (none) Name of a file to be printed before the user has authenticated successfully.
PasswordAuth boolean no 1 Set to 0 to disable authenticating with passwords.
Port integer no 22 Port number to listen on.
RootPasswordAuth boolean no 1 Set to 0 to disable authenticating as root with passwords.
RootLogin boolean no 1 Set to 0 to disable SSH logins as root.
GatewayPorts boolean no 0 Set to 1 to allow remote hosts to connect to forwarded ports.
Interface string no (none) Tells dropbear to listen only on the specified interface. (e.g. lan, wan, wan6)
keyfile file no (none) Path to host key file.
rsakeyfile file no (none) Path to RSA host key file. Deprecated. See keyfile.
SSHKeepAlive integer no 300 Keep Alive
IdleTimeout integer no 0 Idle Timeout
mdns integer no 1 Whether to announce the service via mDNS
MaxAuthTries integer no 3 Amount of times you can retry writing the password when logging in before the SSH server closes the connection from this commit

This is the default configuration:

# uci show dropbear

Add a second instance of dropbear listening on port 2022.

uci add dropbear dropbear
uci set dropbear.@dropbear[-1].RootPasswordAuth="on"
uci set dropbear.@dropbear[-1].PasswordAuth="off"
uci set dropbear.@dropbear[-1].Port="2022"
uci commit dropbear
/etc/init.d/dropbear restart
  • Set up public key authentication and disable password authentication if possible.
  • Set up a VPN to avoid exposing SSH to the internet and as a single critical vulnerability may be enough for a remote attacker to gain root access.

Problems facing with a public SSH:

  • No normal group for users and no normal user.
  • No facility to ban IPs with many failed login attempts.
  • File system permissions are very lax on default OpenWrt.
  • Preventing normal users from exploiting BusyBox to gain access to root only commands due to missing permissions for symlinks.
This website uses cookies. By using the website, you agree with storing cookies on your computer. Also you acknowledge that you have read and understand our Privacy Policy. If you do not agree leave the website.More information about cookies
  • Last modified: 2021/05/11 07:19
  • by highpost