AnsweredAssumed Answered

Using dropbear in an nfsroot environment

Question asked by lastman on Aug 15, 2012
Latest reply on Aug 17, 2012 by lastman



I am booting my bf537 hardware over nfsroot when I am doing development and debugging. I am also using dropbear with public key authentication. Unfortunately, dropbear does not cooperate in this configuration, because when first run, it checks the permissions of all components of the /root/.ssh/authorized_keys path. Because I am developing and building as a regular user, dropbear's permission check fails and dropbear falls back to password authentication.


When I tweak romfs so that the /root/.ssh/authorized_keys path has the correct permissions, dropbear succeeds and everything works. But I really can't change the permissions of romfs to make dropbear happy, because I am building as a regular user. To resolve this, I first allowed my user id to run the chown command as root, using the sudo package. Basically, my vendor specific makefile would adjust romfs so that the /root hierarchy is owned by root. When cleaning, the vendor specific makefile would mark the /root hierarch back to normal user and then would delete it. But I hated this solution, because it would only work for me as a regular user and another developer would have to tweak the makefile to make it work for him.


So, I am contemplating to add a new command line option to dropbear (-l maybe). When this option is given, dropbear will not enforce correct permissions for /root/.ssh/authorized_keys. When doing development using nfsroot, I will pass this option, but during normal operation, this option will not be passed and dropbear will behave as usual.


So what do you guys think about this solution? Is there a better solution for this case?