Hi there I’m new to DietPi and Dropbear but I’m honestly loving the Distro so far especially for the this particular setup… although currently I’m having issues configuring Dropbear for SSH purposes…
I’ve disabled Root Logins by adding the -w argument in the “/etc/default/dropbear” config file…
This has seemed to work because both Root and the Default dietpi user hand out permission denied errors whenever attempting to login via SSH on a separate machine… although when I attempt to login as a normal user with sudo or without sudo privileges I get a connection closed error…
Search Engines and Documentation have been useless so far, Thus I’m truly hoping someone here can help me solve this little issue, Any help is greatly appreciated thanks!
usually user dietpi should still have access as you lockout user root only. Probably something wrong on your Dropbear server. Do you still have local access to the system? Did you tried to reboot.
I did a small test and added -w option
# any additional arguments for Dropbear
DROPBEAR_EXTRA_ARGS=-w
once Dropbear was started, root was not able to login but user dietpi is still working
I had a feeling something was wrong early on because the dietpi user refuses to login physically at the device or via ssh from the start… even with root ssh login enabled I wasn’t able to login as any personal or even the dietPi User…
As you suggested I have tried rebooting multiple times through a safe shutdown or reboot command this sadly hasn’t helped…
I do have physical access to the Pi4 thus I have confirmed that the DropBear Service was running via a “systemctl status” command…
first revert your change and remove -w flag. Than we would need to check why no other user (except root) can login. What happen if you login as root and try following
Quick Update, So it seems the password change for the dietpi user wasn’t properly applied during the “dietpi-config” I’m guessing this may be a bug because I attempted to change the password twice for the dietpi user via the “dietpi-config” GUI… both attempts seemed to have been unsuccessful and I simply didn’t notice till I tried changing the password once again via the passwd command…
It’s entirely possible I made a typo during that process because the default password didn’t work either prior or after the change via the gui… thus I expect if it is a legitimate bug that it will be reproducible…
After the password change and another reboot I was finally able to login as the dietpi user via ssh… Root provides a permission denied error which is desired, although my other two personal users… one with sudo privileges the other without still provide a connection closed error…
Any idea why those users aren’t allowed to connect via SSH?
Was I possibly supposed to add them to a group related to dropbear?
I did a quick test changing the password using dietpi-config and I was not able to replicate the behaviour. For me, the password for user root as well as user dietpi was changed correctly
root@DietPi3:~# dietpi-config
[ SUB1 ] DietPi-Set_software > passwords ()
[ INFO ] DietPi-Set_software | "root" and "dietpi" login passwords successfully changed
[ OK ] passwords | Completed
root@DietPi3:~#
Ah it’s good to know that it wasn’t a bug, I also did another test having the same issue on my side, although I think I’ve pinpointed my issue, I had my local settings incorrectly set thus the password I inputted would have been quite different compared to typing on my other machine over SSH…
I just didn’t realize till I noticed that manually changing it pyshcially at the Pi would have the same effect as changing it in the dietpi-config utility… after a local change via the dietpi-config it all works as expected…
Now that brings me to my final question why does Dropbear accept dietpi user yet close the connection to any other non root user?
Via a “useradd” and “passwd” command, I use them to access network shares, they aren’t usable via SSH which is fine with me although I’m still curious why they won’t be accepted over SSH…
hmm I’m not able to replicate your behaviour. I created a simple demo user using adduser, and was able to login via SSH right after.
root@DietPi3:~# adduser demo
Adding user `demo' ...
Adding new group `demo' (1001) ...
Adding new user `demo' (1001) with group `demo' ...
Creating home directory `/home/demo' ...
Copying files from `/etc/skel' ...
New password:
Retype new password:
passwd: password updated successfully
Changing the user information for demo
Enter the new value, or press ENTER for the default
Full Name []: x
Room Number []: x
Work Phone []: x
Home Phone []: x
Other []: x
Is the information correct? [Y/n] y
root@DietPi3:~#
─────────────────────────────────────────────────────
DietPi v7.2.3 : 22:54 - Sat 06/05/21
─────────────────────────────────────────────────────
- Device model : RPi 3 Model B+ (armv7l)
- Uptime : up 1 minute
- CPU temp : 39'C : 102'F (Cool runnings)
- LAN IP : 192.168.0.12 (eth0)
- Info Text : !!! DEMO 32bit !!!
─────────────────────────────────────────────────────
demo@DietPi3:~ $
are you able to share cat /etc/passwd
Probably you might going to hide personal data
After a few tests I have no ideea what is the problem but there are the facts:
when I create a new user with ‘useradd’ command the same behaviour like topic initiator, Dropbear SSH closing connection when attempting to connect with this new user
but
when I create a new user with ‘adduser’ expected behaviour was happened, I can login through SSH using this new user
doru - is the user made with ‘useradd -M’ - I can’t SHH login with this user
doru2 - is the user made with ‘adduser’ - I can SHH login with this user
(post edit)
I made another user
doru3 - with ‘adduser --no-create-home’ option and I can’t login through SSH
( chown /dev/pts/0 0 0 failed: Operation not permitted )
‘useradd -M’ and ‘adduser --no-create-home’ make the same things …
Thank you
(later edit)
I found somewhere in a debian documentation what is the difference between these two commands:
‘useradd’ is the oldone
‘adduser’ is the newone based on ‘useradd’ command but build it with perl Debian documentation ‘strongly recommend’ (maybe not exact words but something like these) to use ‘adduser’ command
instead of ‘useradd’.
