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.

Download
http://matt.ucc.asn.au/dropbear/dropbear-0.52.tar.bz2

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.

$ export PREFIX=/opt/STM/STLinux-2.3/devkit/sh4/target/usr/local
$ export HOST=sh4-linux
$ export BUILD=i386-linux
$ export COMPILER=sh4-linux-gcc

Configuration

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:

$ CC=$COMPILER ./configure --build=$BUILD --host=$HOST --prefix=$PREFIX

Compilation

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:

$ make PROGRAMS="dropbear dropbearkey scp" STATIC=1 MULTI=1

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

$ make PROGRAMS="dropbear dropbearkey scp" STATIC=1 MULTI=1 install

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:

# $PREFIX/../.. is target's root filesytem: /opt/STM/STLinux-2.3/devkit/sh4/target/
# Copy the real executable dropbearmulti to the target's root filesystem /usr/local/bin
$ cp dropbearmulti $PREFIX/bin

# Create the symbolic links dropbearkey and dbclient
$ ln -s dropbearmulti dropbearkey
$ ln -s dropbearmulti dbclient

# Create the symbolic link scp in the target's filesytem /usr/bin
$ cd $PREFIX/../bin
$ ln -s ../local/bin/dropbearmulti scp

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

$ cd $PREFIX/bin
$ sh4-linux-strip dropbearmulti

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:

$ make scp

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:
SSH: http://en.wikipedia.org/wiki/Secure_Shell
Public-key cryptography: http://en.wikipedia.org/wiki/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):

$ mkdir -pv /etc/dropbear
$ cd /etc/dropbear

# Generate the RSA private and public keys.
$ dropbearkey -t rsa -f dropbear_rsa_host_key
Will output 1024 bit rsa secret key to 'dropbear_rsa_host_key'
Generating key, this may take a while...
Public key portion is: 
ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAAAgncEwjavI+PfbQ+WNDYev/g2f5PGTD7ZzAnauZP4dWOi0MTVFGOZXTf9/cWXwx12zZ2KUOS5UfWk9SdH/t67MPVDDptFaq0kJ5ReA6JzqhwaKguMIdNGTdM2HfwJabvSnDL4SZgpxXtOJYZhWaqMMO8OP560gE21h6O0mH75/IBJUak=
root@my_target
Fingerprint: md5 0a:bb:43:82:41:7b:8a:8b:4d:41:43:e7:71:54:a7:ce

# Generate the DSS private and public keys.
$ dropbearkey -t dss -f dropbear_dss_host_key
Will output 1024 bit dss secret key to 'dropbear_dss_host_key'
Generating key, this may take a while...
Public key portion is: 
ssh-dss
AAAAB3NzaC1kc3MAAACBALIEmhf5c65czi/2rq1Xu2I0Vv+DqeEUQDDmeFke4nyBqVOuQTq8JrHzuRz8SbeohqhXWx//546HLK/RwIG6Gkj5+RQ7uvcc9bcprwJtQVU+U1qmgepPsl6e0Cofldbz+LBLWE5R1sg1ExX/NzGNtKzIbukXUABK12/sveGODeWpAAAAFQCNmGPNFcQyso8x+Zc52FLuRrtTfQAAAIEAiN4pNvhdyNX0lg1nop0ei+qp7H8kmurXWhZMZmaKWVYOc8YqvELL/U1s9fNNPsxEBTi6ysYLM1MCHNizQ4x/npsC/1e6URaIub/Dtf55N5Bn1LaItdK2EO1wLemf1/+3yuvJvhvI2yaPEEAzIgmQatTdE38HwY3+AxXSgccqsBcAAACBAJv9gJtcu5rHGal4VCaVRcM41z+omA7agAtcpmcXOBXr719T2qSZF+GoAeLlfThndaCTchpDQXNDxwTaW6G9RxGOhrDgyKR4MgShljnBfq0wsVx06l23Ex92d8xSmXJz4E/BwtLhjUouAsrW/IJbxQlwp3stmvtik6IYP/BiM2kf
root@my_target
Fingerprint: md5 a7:ad:8e:f8:d2:78:73:ec:a7:1b:aa:ba:9b:ad:aa:2a

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:

$ dropbear 

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:

# Connect from host (client) to target (server) using SSH.
# It will prompt for root's passwd.
$ ssh root@192.168.0.135

# Copy the file 'hola' from the host (client) to the directory /etc in the target (server).
# It will prompt for root's passwd.
$ scp hola root@192.168.0.135:/etc/hola

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:

# Key creation in the host (client) using OpenSSH:
$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa): y
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in y.
Your public key has been saved in y.pub.
The key fingerprint is:
74:84:22:e2:f9:6d:fc:b5:b1:72:40:58:e2:23:ff:ea user@my_client
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|         .       |
|    . . o ..     |
|   . . +o.  .    |
|    . . S..o.    |
|     . o.+..o.   |
|        . ....   |
|          o. ..  |
|         ..+B=+. |
+-----------------+

You will end-up with the private key id_rsa and public key id_rsa.pub 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:

#undef NON_INETD_MODE
#define INETD_MODE

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

22 stream tcp nowait root /usr/local/bin/dropbear dropbear -i

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.

Conclusion
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 *