Dropbear suddenly needs dss_host_key?

Troubleshooting
1

Creating a bug report/issue

Required Information

  • DietPi version | cat /boot/dietpi/.version: 8.9.2
  • Distro version | echo $G_DISTRO_NAME $G_RASPBIAN: bullseye 0
  • Kernel version | uname -a: Linux DidBackup 5.15.61-v8+ #1579 SMP PREEMPT Fri Aug 26 11:16:44 BST 2022 aarch64 GNU/Linux
  • SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3): RPi4/4
  • Power supply used | (EG: 5V 1A RAVpower): Raspberry Pi official
  • SD card used | (EG: SanDisk ultra): none (running on SSD)

Additional Information (if applicable)

  • Software title | (EG: Nextcloud): Dropbear
  • Was the software title installed freshly or updated/migrated?: no
  • Can this issue be replicated on a fresh installation of DietPi? No idea really
    ← If you sent a “dietpi-bugreport”, please paste the ID here →
  • Bug report ID | echo $G_HW_UUID

Steps to reproduce

  1. I was running the RPi for a couple of weeks and everything was fine; connecting remotely by SSH
  2. This morning, I couldn’t SSH anymore into the machine. Had to reboot it (power off/on) and found out that Dropbear was having an issue with journalctl -u dropbear:
Oct 29 02:17:04 DidBackup systemd[1]: Starting LSB: Lightweight SSH server...
Oct 29 02:17:04 DidBackup dropbear[331]: Failed loading /etc/dropbear/dropbear_dss_host_key

Expected behaviour

  • Dropbear should continue to work without issues…
    In the meantime, I created the missing dss_host_key with sudo dropbearkey -t dss -f /etc/dropbear/dropbear_dss_host_key

BUT why does Dropbear restart at 2:17? And why suddenly did it need dss_host_key?

2

The missing file is not an issue. It’s same on my systems, and they are working fine. This is mare a warning and not an error. You should see the message Dropbear has been started on the lines below.

Oct 24 23:41:34 DietPi systemd[1]: Starting LSB: Lightweight SSH server...
Oct 24 23:41:35 DietPi dropbear[282]: Failed loading /etc/dropbear/dropbear_dss_host_key
Oct 24 23:41:35 DietPi dropbear[286]: Running in background
Oct 24 23:41:35 DietPi dropbear[276]: Starting Dropbear SSH server: dropbear.
Oct 24 23:41:35 DietPi systemd[1]: Started LSB: Lightweight SSH server.

This is the last valide time stamp on your system and was set while the system has been rebooted. I guess, checking the entire system log will give a better view on the sequence of actions. There should be a time sync later switching to your actual local time. Probably your system crashed during night. But this has nothing to do with the warning message in Dropbear.

3

Thanks Joulinar for the explanation.
You’re right, it seems that this 02:17:04 timestamp is just the time before the time synchronization and doesn’t mean anything.
Indeed, it seems like something broke this night. I thought it was related to dropbear because I couldn’t SSH in anymore. I got an error each time (“Permission denied (publickey).”), but I didn’t change a thing (I log in with certificates only, so this was highly suspicious).
I guess there is no way to find the log of what caused the crash (since I already rebooted)? Is there a way to change this for the future in case this represents itself?

4

correct, logs will be cleared on reboot

You could try following to enable persistent system logs:

dietpi-software uninstall 103 # uninstalls DIetPi-RAMlog
mkdir /var/log/journal # triggers systemd-journald logs to disk
reboot # required to finalise the RAMlog uninstall

Then you can check system logs via:

journalctl

which will then show as well logs from previous boot sessions. To limit the size, you can additionally e.g. apply the following:

mkdir -p /etc/systemd/journald.conf.d
cat << '_EOF_' > /etc/systemd/journald.conf.d/99-custom.conf
[Journal]
SystemMaxFiles=2
MaxFileSec=7day
_EOF_

This will limit logs to 14 days split across two journal files, so that with rotation you will always have between 7 and 14 days of logs available.

5

hi Joulinar,
This night the issue happened again. I couldn’t SSH into the machine; again, same error message:
Permission denied (publickey).

I did make the changes you suggested to keep logs after a reboot, but it didn’t work. I had to power cycle the Raspberry Pi to get in by SSH again, but then journalctl only showed the log of the reboot. What could I have missed?

6

are you able to login via user/password? If disabled, you could enable it for testing to be able to login while your SSH key is not accepted.

Check the changes done again and perform a reboot for testing. Usually this should keep your logs available.

7

Thanks Joulinar, I added back password login just in case.
I am having some issues again, but it looks like it’s a time server problem; I will have to investigate further before I can create a new post with details.

8

does the time is drifting? usually system time should be updated once a day.

9

No, it wasn’t drifting, it was just totally wrong :frowning:
I guess the NTP call didn’t get through before the network came up. Then unbound was totally lost because of the incorrect time, and that messed up everything (if you don’t have DNS…).
How can I make sure the NTP call waits for the network?

10

Usually, it should not start before the network is online. But even with incorrect system time and without DNS, system should start normally and allow SSH access.

11

Absolutely, SSH is working, as the assigned IP is static (router reservation).
As this is a distant machine, I have to look a little more into what is happening over the next few days and I’ll report back.

12

maybe better to open a new issue if it is not related to SSH anymore. Just to avoid a mix of topics.