Compiling and running Dropbear: a thin Secure Shell server

By | May 12, 2010

Dropbear is a thin Secure Shell 2 (SSH 2) server and client. It is a good alternative to OpenSSH when you have storage and memory restrictions, specially in embedded systems.

Cross-compiling and running Dropbear in an embedded system is not a difficult task, but the documentation is not very clear for everybody. You can start by reading the README and INSTALL files contained in the package and then, if you still have questions, you can keep reading this article in which I’ll try to give a short and clear explanation:

As you may expect from a package of this kind that was written with embedded systems in mind, it supports uClibc. The configuration, compilation and installation are the same as for libc, but it can have some tweaks that are described in the INSTALL file.


Environment configuration
As normal, set the environment variables that make our life easier. Change them according to your needs.
I normally have an SH4 based processor in my desk at home.


Dropbear doesn’t have a configure script since it’s not based on autotools. It contains an options.h file in which you can select many parameters that vary from the keys installation paths to the supported encryption algorithms and X11 forwarding among others.
I strongly suggest you to have a look at this file. This will give you a good idea of what Dropbear is capable of.
In any case, I list here what I consider some of the most relevant options for embedded systems:

  • Small footprint – A speed performance price must be paid when using some ciphers
  • Six supported ciphers – 3DES, AES128, AES256, Blowfish, Twofish128 and Twofish256
  • Adjustable size of receive window size and maximum size of transmission and reception packets

Some other default functionality in OpenSSH are supported in Dropbear too, but are not very relevant for embedded systems such as X11 forwarding.

Once you have decided the options that you need, the configuration is straight-forward as many other packages:


The compilation is the step that allows you to choose the services that you want in Dropbear: the generated binary is a multi-purpose executable that contains the functionality that you need. Here you can select if you want an executable that works as a server (dropbear), that generates keys (dropbearkey), that allows Secure Copy (scp), Secure FTP (sftp), and keys conversion from OpenSSH to Dropbear format (dropbearconvert and dbclient).
If you want at least two of this services you need to give to make the argument PROGRAMS=”the programs that you want” and the MULTI=1 argument.

In this same step you can choose if you want a dynamically or statically – linked executable. For embedded systems is common to use a statically linked executable by adding the STATIC=1 argument to make.

A final make command that contains the Dropbear server, it’s key generation and Secure Copy, looks like follows:

You can use the standard method for installing Dropbear plus the same arguments used during compilation:

But this will use the default path that some times in embedded systems is not sufficient because different paths can be used. In these cases you’ll have to copy manually the executable called dropbearmulti to the desired location and create symbolic links that have the name of the program that you want to use that point to this executable. If you have used Busybox, the concept of symbolic links pointing to the same executable will be familiar:

Stripping is quite a good thing when you need to save storage:

Dropbear 0.52 ships with an alternative standalone scp program that is taken from OpenSSH. If you want to use this instead of the default built-in, you need to compile it separately:

For further compilation hints you can take a look at the SMALL and MULTI files provided in the package.

Keys creation

SSH uses public-key cryptography to authenticate a remote client. Thus, once you have Dropbear properly installed, but before using it, you need to create the cryptographic keys.
You can read the following links for an in-depth explanation of how SSH and public-key cryptography work:
Public-key cryptography:

You can create your keys using two different methods: RSA and DSS.
Both kind of keys seem to be equally secure, but RSA seems to be faster for signature verification that is the most common operation when using the keys.

Let’s create the keys using both methods.
Connect to your target via serial or telnet (at the end of this post you will, hopefully, use ssh instead of telnet):

Be sure that the private keys generated in /etc/dropbear remain secret!
The generated public keys shown in this post are just an example.

Connect to the server using Dropbear

At this point you are able to connect to the target using your login/passwd. Normally in an embedded system the only user is root.

Start dropbear server in the target:

Check the different execution options using the –help flag.
Optional, but recommended, is to add in /etc/hosts in the target’s filesystem the hostname of the client (host).

Finally, you can use ssh and scp:

If you need to connect very often to the target, typing the passwd each time can be very annoying and could pose a security risk.
It would be better not to send the passwd at all.

For this purpose you can store the public key of your host (client) in the target (server).
Assuming that your host (client) is a Unix machine that has OpenSSH installed, you can easily create your keys:

You will end-up with the private key id_rsa and public key in /home/user/.ssh/.
Copy the host’s (client) public key to ~/.ssh/authorized_keys in the target’s filesystem. Notice that ~ is normally /root, but if you’re logging in with another username, change it accordingly.
Warning: If you copy-paste the public key, check that your text editor copies-pastes it correctly, otherwise you will end-up with a broken key. You’re safe if you use vi.

Once you have your host’s (client) public key in your target’s (server) filesystem, you can login to your target without using a passwd speeding up your login procedure!

Running from inetd

If you want to use Dropbear from inetd you have to enable it in the options.h file before compiling:

In the inetd.conf configuration file you have to add the following line:

Notice that if you compile with inetd support, Dropbear will refuse to start from the command line. Obviously, this applies for the other way around too.

Having a working Dropbear server is not a difficult task. You only have to pay attention at compilation time of the services you want from it, and when running it, of the location where you have to store the keys, specially if you want to use them for logging in without a passwd.
Reading the INSTALL, README and other instruction files is always a good idea, no matter how extensive they are.

Leave a Reply

Your email address will not be published. Required fields are marked *