This tutorial shows the steps in order to have two system communicating via SSH, the Secure Shell. SSH has been widely used for server tasks such as remote maintenance, still SSH can be used in a variety of systems such as embedded boxes. Many obstacles come during embedded development, SSH is one more tool that assists developers in numerous ways such as deployment & debugging tasks. This tutorial will cover requirements, key generation, authorization, among other important details; several instructions from this tutorial apply for other SSH clients and servers.
- iMX 7D running Linux 3.14.52
- Server: Dropbear 2016.73
- Ubuntu 14.04 running Linux 4.4.0-45
- Client: OpenSSH
SSH is a software technology that permits system administration over insecure networks, it is a protocol that allows users to transfer files and perform remote login securely. Users can use conventional username and password authentication, but in the SSH world keys are widely used for a number of reasons; automation, security, self-provision and non-expiracy are just a few. This tutorial will show how to generate keys for both, server and client.
SSH Server / Dropbear Setup
Dropbear SSH is a small memory footprint SSH implementation, particularly useful for memory constrained environments such a embedded systems that run Linux.
$ wget https://matt.ucc.asn.au/dropbear/dropbear-2016.73.tar.bz2
You can extract using the tar command or any other file management tool.
$ tar xpf dropbear-2016.73.tar.bz2
This tutorial will not cover cross compilation in detail, for instructions you can run the configuration script that comes with the package:
$ ./configure --help
Mainly you’ll have to set the proper configuration options, for example
--prefix=/usr --exec-prefix=/usr --host=your_toolchain_var CFLAGS=your_cflags LDFLAGS=your_ldflags
SCP has become quite used lately for network copy operations, still SCP doesn’t comes with the default Dropbear build. Setting/exporting the PROGRAMS variable enables SCP alongside the other components for the build:
PROGRAMS="dropbear dbclient dropbearkey dropbearconvert scp"
Having your configuration and variables set, you can compile the package using make.
Consider using the DESTDIR variable, so your binaries go to the destination filesystem (that will probably go the an SD card image).
$ make install DESTDIR=$YOUR_DESTFS
For the client to request a connection, the target board needs to run the Dropbear server daemon. The Dropbear service needs also some requirements to work properly, this document will check those first.
SSH keygen for server
Keys are needed on both sides. For the target board the default location for the keys is the /etc/dropbear directory, create them using the dropbearkey command:
RSA_KEYFILE=/etc/dropbear/dropbear_rsa_host_key DSS_KEYFILE=/etc/dropbear/dropbear_dss_host_key dropbearkey -t dss -f $DSS_KEYFILE dropbearkey -t rsa -f $RSA_KEYFILE
Dropbear is strict with permissions, set/check the permissions for the /etc/dropbear directory
chmod 700 /etc/dropbear
For remote access the embedded target needs a mounted pseudo terminal device (/dev/pts), for a fully-featured embedded distribution you may not need to worry about this, if you are working with a custom distribution is good to make a check on this to discard login issues:
mount | grep pts none on /dev/pts type devpts (rw,relatime,mode=600,ptmxmode=000)
This command shows if there is a mounted filesystem with a ‘pts’ keyword match on it, this output shows that effectively there is a devpts mounted. Notice that permissions over this device can affect remote login, allowing some users to login and others don’t.
SSH login notes
Allowing login to a host system using Dropbear can present security implications. Depending on your implementation, it may not be recommended to use Dropbear for production. Considering any use case it is important to review the Dropbear configuration to avoid unintended security holes. During development, teams usually want full control over the target, this guide uses the root user for its examples. Here is an small checklist concerning user login:
- Check user permissions and groups
- Check that user directory and the respective .ssh/ directory exists, Dropbear may need it to look for keys
- Check that the user will not have conflicts with the Dropbear service options you intend to use
SSH client / OpenSSH Setup
$ sudo apt-get install openssh-client
SSH keygen for client
Create a key on the client PC:
$ ssh-keygen -t rsa
You should have by now a key in ~/.ssh/id_rsa.pub file
$ cat ~/.ssh/id_rsa.pub ssh-rsa AAAAB3NzaC1yc ... # your recently created key
Select the key with the cursor and copy it, you need to paste it inside an authorized_keys file on the target board:
# This is run on the target # This example uses the 'root' user touch /root/.ssh/authorized_keys # AFTER THE 'cat' COMMAND PASTE KEY cat > /root/.ssh/authorized_keys
Check the file
cat /root/.ssh/authorized_keys ssh-rsa AAAAB3NzaC1yc ... # your recently created key
Change file mode
chmod 600 /root/.ssh/authorized_keys
SSH example 1: Run Dropbear & login
Review the Dropbear options before running it to have the service working as you expect
dropbear -h Dropbear server v2016.73 https://matt.ucc.asn.au/dropbear/dropbear.html Usage: dropbear [options] -b bannerfile Display the contents of bannerfile before user login (default: none) -r keyfile Specify hostkeys (repeatable) defaults: dss /etc/dropbear/dropbear_dss_host_key rsa /etc/dropbear/dropbear_rsa_host_key ecdsa /etc/dropbear/dropbear_ecdsa_host_key -R Create hostkeys as required -F Don't fork into background -E Log to stderr rather than syslog -m Don't display the motd on login -w Disallow root logins -s Disable password logins -g Disable password logins for root -B Allow blank password logins -j Disable local port forwarding -k Disable remote port forwarding -a Allow connections to forwarded ports from any host -p [address:]port Listen on specified tcp port (and optionally address), up to 10 can be specified (default port is 22 if none specified) -P PidFile Create pid file PidFile (default /var/run/dropbear.pid) -i Start for inetd -W <receive_window_buffer> (default 24576, larger may be faster, max 1MB) -K <keepalive> (0 is never, default 0, in seconds) -I <idle_timeout> (0 is never, default 0, in seconds) -V Version
Now you can run the service (you can prepare yourself also a nice init script)
DROPBEAR_ARGS=-sg start-stop-daemon -b -S -q --exec dropbear -- $DROPBEAR_ARGS
Use the ifconfig command to determine your target’s IP address, for this example the IP address is 192.168.1.3.
$ ssh firstname.lastname@example.org # whoami root
SSH example 2: Secure copy
$ echo "1 2 3" > scp-example.txt $ scp scp-example.txt email@example.com:/root scp-example.txt 100% 6 0.0KB/s 00:00
Checking copy ..
ls /root/ scp-example.txt cat /root/scp-example.txt 1 2 3
Is possible that your embedded distro still has something missing for Dropbear to work. Here are some tips to help you debug the Dropbear service:
- Redirect Dropbear logs to stderr
- Run the ssh client with verbose
# ssh with verbose level 3 $ ssh -vvv firstname.lastname@example.org
- Read the reference manuals, when Dropbear is built it also comes with man pages
Dropbear has become more present lately on embedded targets as a tool for development, working with SSH keys allow users to get rid of the password authentication step to perform network login and copy operations more straightforward. Watch for correct permissions (users, directories, ..) and server options to avoid unnecessary security holes in your system but to also have a functional working environment.