Author Topic: Dropbear Keeps Regenerating Machine Key (Read 5224 times)

agraef · « **on:** December 28, 2006, 09:18:39 am »

First, kudos to the OZ team for this release, it really works great for me except for the "altboot hangs on boot from loopfile" bug and the following minor issue.

I have Oz 3.5.4.1 on a C-1000 installed, altbooted from an SD card (direct install). Network via WLAN works great, but I have troubles with dropbear which regenerates the machine rsa key on every reboot. Of course that means that on my desktop I have to remove the key from .ssh/known_hosts every time I have to reboot the Z. This happens with both Opie and GPE. I don't have this problem with OZ installed in the flash, though.

I took a look at /etc/init.d/dropbear and noticed that on SD I have a dropbear_rsa_host_key file in *both* /etc/dropbear and /var/lib/dropbear. The relevant lines in /etc/init.d/dropbear are:

Code: [Select]

readonly_rootfs=0
for flag in `awk '{ if ($2 == "/") { split($4,FLAGS,",") } }; END { for (f in FLAGS) print FLAGS[f] }'   case $flag in
   ro)
     readonly_rootfs=1
    ;;
  esac
done

if [ $readonly_rootfs = "1" ]; then
  mkdir -p /var/lib/dropbear
  DROPBEAR_RSAKEY_DEFAULT="/var/lib/dropbear/dropbear_rsa_host_key"
  DROPBEAR_DSSKEY_DEFAULT="/var/lib/dropbear/dropbear_dss_host_key"
else
  DROPBEAR_RSAKEY_DEFAULT="/etc/dropbear/dropbear_rsa_host_key"
  DROPBEAR_DSSKEY_DEFAULT="/etc/dropbear/dropbear_dss_host_key"
fi

So it seems that when booting from SD the startup script is invoked while the rootfs is still mounted readonly, in which case the script generates a new key in /var/lib/dropbear even though there is already one in /etc/dropbear.

Just commenting out the lines which check the rootfs (so that readonly_rootfs is always 0) works around this, but of course this will only work if you're sure that there's already a keyfile. It seems that to really solve that issue the logic in the script which tests for an existing keyfile needs an overhaul, but before I do that I wanted to ask whether anyone else has already noticed this and maybe found a proper fix. (I couldn't find anything in OE bugzilla, so I can also submit a bug report if necessary.)

Da_Blitz · « **Reply #1 on:** December 28, 2006, 09:23:24 pm »

if [ $readonly_rootfs = "1" ]

seems to be the offender, check it. the problem may not be that your root FS is RO when you can open a terminal but that it might be RO during boot, which most linux distros do (that way they can do a fsck if need be

working out if its RO during boot at the wrong time might be hard, or you may be right and the detection code needs an overhaul

agraef · « **Reply #2 on:** December 28, 2006, 09:44:10 pm »

Quote

if [ $readonly_rootfs = "1" ]

seems to be the offender, check it. the problem may not be that your root FS is RO when you can open a terminal but that it might be RO during boot, which most linux distros do [div align=\"right\"][a href=\"index.php?act=findpost&pid=149399\"][{POST_SNAPBACK}][/a][/div]

Yes, that's my analysis as well. But, as this problem only surfaces when booting from SD (rather than flash) there must be some difference in the boot sequence when altboot boots from SD. Maybe that is the real issue?

Of course I could just get rid of the $readonly_rootfs test (that's essentially what I do if I comment out the code which checks for the rootfs, a few lines above), but that's not a foolproof solution. If the rootfs is mounted read-only and no keyfile exists yet (maybe first boot after a fresh installation), there is no other option than to write the newly created keyfile into ram. The situation where the current script goes wrong is when the rootfs is r/o (during boot), but a keyfile already exists in /etc/dropbear. Then that file should be used, but the current script errorneously chooses to create a new keyfile under /var/lib. You can clearly see that in the few lines of the script I quoted above.

Oh well, I guess I'll just post a fixed script here tomorrow and leave it up to the OE guys to decide what to do about this...

agraef · « **Reply #3 on:** December 29, 2006, 07:32:31 am »

Ok, I figured this one out. In fact the rootfs *is* mounted rw when the dropbear init script runs, but I found that after booting from SD with altboot, / is actually mounted *thrice*. Here are the relevant lines from the output of "cat /proc/mounts":

Code: [Select]

rootfs / rootfs rw 0 0
/dev/mmcblk0p1 / ext2 rw,nogrpid 0 0
/dev/mtdblock2 / jffs2 ro,noatime 0 0

Is that normal?? Anyway, if you take a look at the awk command which parses that output in the init.d/dropbear script:

Code: [Select]

awk '{ if ($2 == "/") { split($4,FLAGS,",") } }; END { for (f in FLAGS) print FLAGS[f] }' 
you'll notice that it collects the options from the *last* "/" mount it finds, which is wrong. The solution is to munge the awk command so that it picks up the *first* mount instead:

Code: [Select]
awk '{ if ($2 == "/") { split($4,FLAGS,","); for (f in FLAGS) print FLAGS[f]; nextfile } }' 
Works now.  Patch to the init.d/dropbear script attached. Let me know whether it's useful to file a bug report on that; I'm still not sure whether it's not actually an altboot bug that "/" appears thrice in the mount table.

EDIT: Hmm, attachments still don't work? So here's the patch as a code section:

Code: [Select]
--- dropbear.orig    2006-12-28 13:10:55.000000000 +0000
+++ dropbear    2006-12-29 12:11:33.000000000 +0000
@@ -20,7 +20,7 @@
 test ! -h /var/service/dropbear || exit 0
 
 readonly_rootfs=0
-for flag in `awk '{ if ($2 == "/") { split($4,FLAGS,",") } }; END { for (f in FLAGS) print FLAGS[f] }' +for flag in `awk '{ if ($2 == "/") { split($4,FLAGS,","); for (f in FLAGS) print FLAGS[f]; nextfile } }'    case $flag in
    ro)
      readonly_rootfs=1

koen · « **Reply #4 on:** December 29, 2006, 07:35:44 am »

Quote

I'm still not sure whether it's not actually an altboot bug that "/" appears thrice in the mount table.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=149437\"][{POST_SNAPBACK}][/a][/div]

Why o why is it so hard for people to understand that you should *always* file a bugreport. The bugtracker is the canonical place to report issues and fixes, not some random forum.

agraef · « **Reply #5 on:** December 29, 2006, 08:31:03 am »

Quote

Why o why is it so hard for people to understand that you should *always* file a bugreport. The bugtracker is the canonical place to report issues and fixes, not some random forum.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=149438\"][{POST_SNAPBACK}][/a][/div]

Why oh why? Maybe I'm just talking to myself here because I'm not sure yet what the bug actually is, so that I can file a decent bug report? So that someone who knows this system better than me (like you for instance) can say "Scratch that, the script is ok, it's a bug in altboot, file a report under that title instead". Also, like it or not, this is not just some random forum here, it gets visited by many Z users and developers alike, so it's a good place for such discussions IMHO.

I know that at times as a developer who has so many things to do, it's not easy to stay calm and well-tempered when users make silly remarks or ask silly questions. But remember that some of us "lusers" may also be experienced developers, albeit in other areas of expertise.

Ok, with that off my chest, I'll file a bug report now. If anyone else has an idea whether this is really an issue with init.d/dropbear or whether there's actually a problem with altboot, please let me know.

Cheers,
Albert

koen · « **Reply #6 on:** December 29, 2006, 08:41:28 am »

Quote

Quote
Why o why is it so hard for people to understand that you should *always* file a bugreport. The bugtracker is the canonical place to report issues and fixes, not some random forum.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=149438\"][{POST_SNAPBACK}][/a][/div]

Why oh why? Maybe I'm just talking to myself here because I'm not sure yet what the bug actually is, so that I can file a decent bug report? So that someone who knows this system better than me (like you for instance) can say "Scratch that, the script is ok, it's a bug in altboot, file a report under that title instead". Also, like it or not, this is not just some random forum here, it gets visited by many Z users and developers alike, so it's a good place for such discussions IMHO.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=149445\"][{POST_SNAPBACK}][/a][/div]

But not visited by 95% of the OE developers, so this forum is not a good place for such discussions.

agraef · « **Reply #7 on:** December 29, 2006, 09:11:38 am »

Quote

But not visited by 95% of the OE developers, so this forum is not a good place for such discussions.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=149446\"][{POST_SNAPBACK}][/a][/div]

I can't verify this number, it might be true. But you post regularly here, Mickey, Hrw, CoreDump, ... I'd say that's already a sizable fraction of the OE/OZ core developers.

agraef · « **Reply #8 on:** December 29, 2006, 09:36:52 am »

Ok, I've reported this issue in the OE bugtracker (#1723).

Hrw · « **Reply #9 on:** December 29, 2006, 12:33:05 pm »

Quote

I can't verify this number, it might be true. But you post regularly here, Mickey, Hrw, CoreDump, ... I'd say that's already a sizable fraction of the OE/OZ core developers. [div align=\"right\"][a href=\"index.php?act=findpost&pid=149448\"][{POST_SNAPBACK}][/a][/div]

I tend to ignore forum bugreports as many times they are written like 'it does not work' or 'it works when I edit file' but came without solutions.

In OE we have bugdays when we work on fixing bugs instead of adding new stuff.

So if someone want to get some fixed he need to report it. Forum posts, Mailing list posts, private posts are not correct way. You can write about bug in forum but devels will rather do not follow this way.

News:

Author Topic: Dropbear Keeps Regenerating Machine Key (Read 5224 times)