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
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
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
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
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