Issue Report: Unable to Authenticate via Password After Reboot on FreedomBox (LDAP & SSH Issue)

Pioneer Support
1

Summary

I recently purchased the Pioneer-FreedomBox-HSK two days ago. After it arrived, I connected it to my router using an Ethernet cable, powered it on, and allowed it to update. Everything was working fine, and I was able to connect via SSH using my password. However, after the device rebooted, I could no longer authenticate via SSH using my password—it kept showing an incorrect password error.

To troubleshoot, I added my public SSH key via the FreedomBox web interface, and I was able to log in successfully without using a password. However, I still want to understand why password authentication stopped working after the reboot and how I can restore it if needed.

Questions

:one: Why is there no userPassword stored in LDAP for my user (imhere)?

  • Before rebooting, SSH password authentication worked, which suggests that it initially relied on PAM and /etc/shadow.
  • After the reboot, FreedomBox switched to LDAP-only authentication, which requires userPassword to be set in LDAP.
  • Since userPassword is missing, LDAP is unable to verify the password, causing SSH login failures.

:two: Why do I not know the LDAP admin password?

  • During installation, FreedomBox does not display the LDAP admin password.
  • Without this password, I cannot modify LDAP entries, such as adding userPassword for my user.
  • Is there a way to retrieve or reset the LDAP admin password?

:three: Why did SSH password authentication work before the reboot but stopped afterward?

  • Before rebooting, it seems that FreedomBox allowed authentication through /etc/shadow.
  • After rebooting, nslcd and slapd were fully enabled, making LDAP the sole authentication method.
  • Since my user lacks a userPassword entry in LDAP, the authentication fails.

:four: Is this behavior intentional in FreedomBox for security/privacy reasons?

  • Does FreedomBox deliberately remove password authentication after the first reboot to enforce key-based authentication?
  • If so, what is the recommended approach for setting up password-based authentication securely in FreedomBox?

Troubleshooting Steps Taken

:heavy_check_mark: Checked if my user exists in LDAP:

sudo ldapsearch -xLLL -b "dc=thisbox" "(uid=imhere)"

Result:

dn: uid=imhere,ou=users,dc=thisbox
objectClass: account
objectClass: posixAccount
cn: imhere
uid: imhere
uidNumber: 10000
gidNumber: 100
homeDirectory: /home/imhere
loginShell: /bin/bash
gecos: imhere
description: User account

Observation:

  • The user exists, but userPassword is missing.

:heavy_check_mark: Checked if userPassword exists in LDAP:

sudo ldapsearch -xLLL -b "dc=thisbox" "(uid=imhere)" userPassword

Result:

dn: uid=imhere,ou=users,dc=thisbox

Observation:

  • No userPassword attribute is set.

:heavy_check_mark: Checked if LDAP authentication is enforced in nsswitch.conf:

cat /etc/nsswitch.conf | grep passwd

Result:

passwd: files ldap

Observation:

  • LDAP is being used for authentication, meaning it will no longer check /etc/shadow for passwords.

:heavy_check_mark: Checked if LDAP admin credentials are known:

ldapwhoami -x -D "cn=admin,dc=thisbox" -W

Result:

ldap_bind: Invalid credentials (49)

Observation:

  • I do not know the LDAP admin password.

Possible Workarounds & Questions for the Community

:small_blue_diamond: How can I retrieve or reset the LDAP admin password in FreedomBox?
:small_blue_diamond: Is there an official way to enable password authentication for SSH without using SSH keys?
:small_blue_diamond: Is it a deliberate design choice that FreedomBox disables password-based authentication after the first reboot?
:small_blue_diamond: What is the recommended way to set up password authentication in FreedomBox while keeping LDAP integration?

Current Workaround (Using SSH Keys)

Since I could not authenticate with a password, I manually added my public SSH key via the FreedomBox web interface. This allowed me to log in without a password. However, I still need guidance on how to properly configure FreedomBox to allow password-based authentication if needed.

:rocket: Any insights from the FreedomBox community would be greatly appreciated!
If this behavior is intended, I believe adding a note about it in the installation documentation would help new users avoid confusion.

2

So “imhere” is a non-admin (regular user) account you created using the admin account you specified during initial setup, and you no longer have the password to the admin account?

The option to enable/disable SSH password authentication is on the System/Secure Shell Server page, and the default is enabled (box unchecked), so unless you checked the box to disable it (using an admin account, since the System page is accessible only to admins), SSH password authentication should be enabled.

You have the password for “imhere” since you were able to log in and use the FreedomBox Web interface to add your SSH public key. If you pull up the Edit page for “imhere”, presumably the same page where you entered the SSH public key, among the permissions listed for “imhere” do you see “Remotely login using Secure Shell (SSH) (freedombox-ssh)” checked? Presumably you checked it when you created “imhere”.

If that permission is unchecked, the mystery would be why you were able to SSH in as “imhere” before the reboot. If that box is checked, the mystery is why you were unable to SSH in as “imhere” using the same password you used successfully to log in to the Web interface. Your SSH client and FreedomBox are on the same network? If the client is on the other side of your router, I think you need to set the router to forward port 22 to the FreedomBox, which doesn’t seem to be as clearly stated on the Secure Shell (SSH) Server manual page as it could be.

However, a bigger problem for managing your FreedomBox is that you don’t have an admin account you can log in with. You may have to start over by writing a fresh image to the SD card and go through the installation process again. It sounds like you just received your Pioneer FreedomBox recently, so maybe starting over wouldn’t be too painful.

3

I only have one account, which is imhere, and it was set up when I installed the system. I believe it is an admin account.

There is an option to enable/disable SSH password authentication on the System → Secure Shell Server page:

  • “Disable password authentication” (unchecked)
  • “Allow all users to log in remotely” (checked)

Edit User Page
Permissions:

  • “Access all services and system settings (Administrator)” (checked)
    • This option is enabled by default, while all other boxes are unchecked.
    • I have not made any changes to these settings.

Yes, the FreedomBox server is connected to the router via an Ethernet cable, and the device I am using to connect via SSH is connected to the same router via Wi-Fi.

4

Since post-reboot you have a functional admin account (are able to log in to the Web UI) and SSH password authentication is not disabled, I would think you’d be able to SSH in with the same userid/password from a client on the same network.

For what it’s worth, I get the same results you did for the troubleshooting commands you listed, but I’m able to SSH in using password authentication to the admin account I set up during installation. I do notice that if I intentionally enter an incorrect password, the message I get is “Permission denied, please try again.”, not something about an incorrect password.

Anything exotic about your password that might require special entry or escaping in some contexts?

You might consider creating a second admin account to try to reproduce the problem and continue troubleshooting without disturbing your imhere account. You can always delete the second account later.

5

When I attempt to connect via SSH and enter the correct password, I receive the following message:

ssh imhere@freedombox.local
imhere@freedombox.local's password: 
Connection closed by 192.168.8.109 port 22

However, I do not receive this message:

Permission denied, please try again.

Before trying any of the suggested troubleshooting steps, I would like to clarify:

  • Does this specific response from SSH (Connection closed by 192.168.8.109 port 22) provide any clear explanation for why the authentication is failing?
  • Is there any known reason why FreedomBox would close the connection immediately after entering the correct password instead of simply denying access with "Permission denied, please try again."?

I appreciate your insights before proceeding with further tests."

6

I’m not knowledgeable enough to provide any more clarity based on the evidence so far. The message is general enough that I think it could have various causes, but I wouldn’t have expected an incorrect password to cause it.

However, I’m seeing the same symptom on a Pioneer running Trixie (not Bookworm, so perhaps not identical to your situation), and I set up a second admin account, added an SSH key to it so that I could SSH in, and took a look at the log after trying and failing to SSH in with the original admin account using password auth. The result is below.

Mar 07 17:28:31 pioneer kernel: Alignment trap: not handling instruction ecb38b02 at [<b668ff2e>]
Mar 07 17:28:31 pioneer kernel: 8<--- cut here ---
Mar 07 17:28:31 pioneer kernel: Unhandled fault: alignment exception (0x221) at 0x00b4bda2
Mar 07 17:28:31 pioneer kernel: [00b4bda2] *pgd=50223003, *pmd=79b76003
Mar 07 17:28:31 pioneer sshd[830]: error: session process 4349 for connection from 192.168.10.101 to 192.168.10.243 killed by signal 7

Right now I don’t know exactly what this means or what to do about it, but my point is just that seeing what shows up in the log when SSH password authentication fails could provide a clue to what’s happening on your system. I just ran “sudo journaltctl -f” in my SSH session established using keys before attempting to SSH in as the other user using password auth.

7

I think the FreedomBox Manual covers this pretty well. Would you check there and see if that solves your issue?

If not reply back here and we can get you sorted. It will be good to know if the manual has a gap for your situation.