Nowadays - in the funny days of IoT - the majority of embedded devices are reachable over the network. This was not the case some years ago and therefore many embedded developers are still dealing with static passwords to log in e.g. over ssh. This was also the case with the initial edi-pi setup. To put it short - I felt very concerned about it.
Here is how I changed it leveraging new edi features:
If you want to move away from static passwords it is an obvious choice to make use of ssh keys. If you are a frequent GitHub user or server administrator it is very likely that you already have a ssh key pair. You can check this as follows:
$ ls -al ~/.ssh
Valid public keys are typically named
If you do not find a key pair it is a good idea to generate one now:
$ ssh-keygen -t rsa -b 4096 -C "firstname.lastname@example.org" Generating public/private rsa key pair. Enter file in which to save the key (/home/YOU/.ssh/id_rsa): Created directory '/home/YOU/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again:
A key pair consists of a public key (e.g.
id_rsa.pub) and a matching private key
id_rsa). Your duty is to make sure that nobody but you has access to the
private key. Therefore further protecting it with a passphrase is a good idea.
If you do not want to re-type the password every time you use the key, a
will do the trick for you.
Creating the Container
Given you have installed edi according to this instructions (version >= 0.11.0) you are now ready to go.
First we build a brand new LXD container from scratch:
$ mkdir ~/my-edi-ssh-demo && cd ~/my-edi-ssh-demo $ edi config init my-edi-ssh-demo debian-stretch-amd64 $ sudo edi -v lxc configure my-edi-ssh-demo my-edi-ssh-demo-develop.yml
Since the container gets built from scratch you have plenty of time to take a look at the output. If you have done the ssh key setup according to the instructions above you should find something like:
edi_current_user_ssh_pub_keys: - /home/YOU/.ssh/id_rsa.pub
edi has identified your public key and will automatically add it to the
authorized_keys files of your container users.
edi will deactivate password based ssh login to the container by
/etc/ssh/sshd_config and adding the line
Accessing the Container
Now we have to figure out the IPv4 address of the container:
$ lxc list my-edi-ssh-demo
And now we can directly access it:
$ ssh IP_OF_CONTAINER The authenticity of host 'IP_OF_CONTAINER (IP_OF_CONTAINER)' can't be established. ECDSA key fingerprint is SHA256:XYZ. Are you sure you want to continue connecting (yes/no)? yes
Now you should have entered the container without the need to type in the password of the container user (which is ChangeMe!).
You can leave the container again:
If you get the message
Permission denied (publickey). something is wrong with
your ssh key setup. You might want to check again if
edi was able to identify
your public key:
$ edi lxc configure --dictionary my-edi-ssh-demo my-edi-ssh-demo-develop.yml ... edi_current_user_ssh_pub_keys: - /home/YOU/.ssh/id_rsa.pub ...
Apart from the personal user in the container you can also access the container by using the default container user (named edi in this example or pi in the edi-pi setup):
$ ssh edi@IP_OF_CONTAINER
and leave it again:
Involving your Team
At the moment, you are the only one that is able to ssh into your container. For
a container setup this might be ok but as soon as you are using
edi to generate
target system images (see e.g.
this blog post) you might
need to authorize your coworkers to access a certain device.
Luckily this is easy! Just collect the public keys (they must have the extension .pub) of the people you would like to authorize and drop them into the newly created ssh public key folder:
$ mkdir -p ~/my-edi-ssh-demo/ssh_pub_keys $ cp *.pub ~/my-edi-ssh-demo/ssh_pub_keys/
Now you can apply those keys to the existing container:
$ cd ~/my-edi-ssh-demo $ edi -v lxc configure my-edi-ssh-demo my-edi-ssh-demo-develop.yml
Congratulations: Your coworkers are now also authorized to access the container by using the default user:
$ ssh edi@IP_OF_CONTAINER
At the age of IoT static passwords that can be used for remote access are a no-go.
We should already avoid them during development to make 100% sure that we never
ship products that can be accessed by a static password.
edi will help you
to make the usage of ssh keys even more convenient.
If your setup gets more complex, be aware that ssh also supports certificate authorities since some time. Please read this blog post to get started.