Drobo

Unable to SSH with password/change ssh password for normal users

I made the mistake of upgrading my Drobo5N’s firmware over the weekend from v3.something to v4.1.4-8. I then had a panic as I was unable to access the unit via ssh (…and I don’t have the data “shared” in the usual way, I just access via sshfs).

Eventually I was able to ssh in with the ‘admin’ account, and all my data was still there - main panic over.

HOWEVER, I am still unable to ssh in with my normal user accounts. The password set via dashboard doesn’t work. If I ssh in as ‘admin’ and sudo up to root, I am able to do “passwd dave” and the /etc/passwd file gets updated, but I still can’t ssh in. If I do some voodoo with ssh keys I can ssh in as ‘dave’, but at this point I can’t just run “passwd” as I get an error stating that passwd must be suid root… and even if I was able to run that, I’m not convinced it would accept the “Old password” I gave it - I certainly can’t sudo as ‘dave’ using the password I set as the admin->root user.

Has anyone else had this issue?

I shall answer my own question.

I was eventually able to set the password for the ‘dave’ user.

I noticed that when root changed the password it was updating /etc/passwd not /etc/shadow. Checking, there was no entry for ‘dave’ in /etc/shadow. I manually added an entry for ‘dave’ in /etc/shadow, copying the password hash that had been written to /etc/passwd, and then edited /etc/passwd to change the password hash there to ‘x’. I was then able to log in via ssh using a passwd, I was able to use sudo (having also manually edited /etc/groups), and changing the password as root then updated /etc/shadow and worked as an ssh passwd. I am still unable to change the user’s password without first being root, but that’s more of a nuisance than a show-stopper.

I fully expect to have to jump through the same hoops next time I reboot the Drobo, since in my experience the files in /etc/ are re-generated on boot.