root login not accessible anymore

Hello,
for some reason today I found that the root login is not anymore accessible. Dietpi v158 is running on a raspi3 and all the services I have running are still correctly accessible with their credentials.
I really don’t understand how that could happen since I’m completely sure I remember the password, it is also saved for automatic login in my ssh client.

Any suggestion?

Thank you very much,
gaggio

  • Check the SSH logs on RPi 3
  • And services
systemctl status dropbear -l
systemctl status ssh -l

Today this happend to me, while testing RPi Zero W installation:

Using:
DietPi_v150_RPi-armv6-(Jessie).img
=> auto update to DietPi v158 during first boot up (incl. DietPi kernel and firmware update)
=> at inital setup dialog change form Dopbear to OpenSSH Server for file access
=> select Install and
=> apt-get upgrade starts to install 45 updated packets and firmware + selected software installation with finally auto-reboot

But no SFTP (SCP) file transfer is possible . So I have checked:

htop

  • see dropbear is running and not OpenSSH Sever

  • checked installed software:

dietpi-software


171208-0004.gif

  • choose now: Dropbear Lightweight SSH Server (Recommended)
 DietPi-Software
─────────────────────────────────────────────────────
 Mode: Uninstall
 Please wait...


 [Ok] Uninstalling OpenSSH Server:

Reading package lists... Done
Building dependency tree
Reading state information... Done
Package 'openssh-server' is not installed, so not removed
  • after auto-reboot reinstall OpenSSH

Sorry no logs, using DietPi-Ramlog.



root@RPi-Zero-W:~# systemctl status dropbear -l
● dropbear.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)
root@RPi-Zero-W:~# systemctl status ssh -l
● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled)
   Active: active (running) since Fri 2017-12-08 15:26:28 UTC; 43min ago

@Fourdee

retested with another fresh installation it the same happend again.

root@RPi-Zero_W:~# systemctl status dropbear -l
● dropbear.service - (null)
   Loaded: loaded (/etc/init.d/dropbear)
   Active: active (running) since Fri 2017-12-08 18:05:55 UTC; 1min 33s ago
  Process: 470 ExecStart=/etc/init.d/dropbear start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/dropbear.service
           ├─ 477 /usr/sbin/dropbear -d /etc/dropbear/dropbear_dss_host_key -r /etc/dropbear/dropbear_rsa_host_key -p 22 -W 65536
           ├─1672 /usr/sbin/dropbear -d /etc/dropbear/dropbear_dss_host_key -r /etc/dropbear/dropbear_rsa_host_key -p 22 -W 65536
           ├─1718 -bash
           └─1786 systemctl status dropbear -l


root@RPi-Zero_W:~# systemctl status ssh -l
● ssh.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)



root@RPi-Zero_W:~# dpkg -l *ssh*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                       Version            Architecture       Description
+++-==========================-==================-==================-==========================================================
ii  libssh2-1:armhf            1.4.3-4.1+deb8u1   armhf              SSH2 client-side library
un  openssh-client             <none>             <none>             (no description available)
un  ssh-server                 <none>             <none>             (no description available)

root@RPi-Zero_W:~# dpkg -l drop*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                       Version            Architecture       Description
+++-==========================-==================-==================-==========================================================
ii  dropbear                   2014.65-1+deb8u2   armhf              lightweight SSH2 server and client

Where are not relevant logs in /var/log/…

Yep, known issue, proving a tricky one to find the cause:
https://github.com/Fourdee/DietPi/issues/1122

Thanks,
So it seems the cause have been spotted, it’s not clear to me how to solve it without being able to login.
I might have missed something obvious…

Thank you,
Gaggio

Hi,

We’ve fixed the OpenSSH failing to install issue, however, I believe your issue is different and not related.

The issue you report is not something i’ve personally experienced, or we can replicate. If you have applied any manual changes to system (outside DietPi scripts), it may be worth back tracking those changes.

Failing that, I’d recommend writing a new DietPi image and starting again.

Thanks Fourdee,
I haven’t changed anything with or without the use of the dietpi scripts before the issue happened. At least I didn’t realize if I was doing so…
However, I took a backup (complete SD image) right before updating to v158, I will try to restore that if no one comes up with any possible solution.
I tried to login as dietpi user via SSH, this is what I get:

:~$ ssh dietpi@192.168.1.136
dietpi@192.168.1.136's password: 

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

[sudo] password for root: 
Sorry, try again.
[sudo] password for root:

Posting here again because the same issue showed up.
Last time I solved the issue restoring a backup taken with v156, before the update to v158.
Then, I stuck with v156 for the last month even if v159 was out.
Now, I’m again stuck with no root login and only able to login as dietpi user, not possible to execute sudo either…
Any issue possibly linked to this behavior identified recently? It would be a little frustratring having to restore every month…
It’s a headless system, might it be worth connecting to a display to login locally? I read there are some issues with SSH, if this can be related.

Many thanks,
gaggio