6

After sitting in the depths of my project desk for a year or so, a Raspberry Pi model B turned up that has data I want to save. It boots up but I deleted the pi user for security reasons and can't remember the username I set.

There is a ton of advice out there for resetting the password by use of the recovery console (init=/bin/sh method) but almost no advice on what to do if you have deleted the pi user and can't remember the username with root privileges. I'm pretty sure I have the password, but I don't have the username. The init=/bin/sh method wasn't working for me.

How can I discover what users exist on my RPi?

8

As it turns out, you don't have to flash your RPi to recover from this. In fact, you don't need another Linux system at all, all you need is another SD card flashed with your RPi OS flavor of choice and a USB SD card reader to put your original SD card in. The init=/bin/sh method did not work for me (I think there was a display conflict with the custom Adafruit kernel needed to use 3.5" TFT screen embedded with the RPi screen) so I used the chroot method which I discuss below. If the init=/bin/sh method works for you, you should be able to use the steps below in the recovery console to achieve a similar result.

My answer to this post was based on my experience with this problem.

Turns out using the chroot method to change your password gives several options to discover your forgotten username. The easiest would likely be to cd /home and then ls to view the directories, but that might not be helpful enough.

Like most things Linux, that is not the only way, there is also the /etc/passwd file. "I looked in there and there are a ton of users I don't know anything about!" Fear not, most of them are task specific and were placed there by software for those tasks. Lets take a look at the file anyway, sudo nano /etc/passwd shows us this:

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
systemd-timesync:x:100:103:systemd Time Synchronization,,,:/run/systemd:/bin/false
systemd-network:x:101:104:systemd Network Management,,,:/run/systemd/netif:/bin/false
systemd-resolve:x:102:105:systemd Resolver,,,:/run/systemd/resolve:/bin/false
systemd-bus-proxy:x:103:106:systemd Bus Proxy,,,:/run/systemd:/bin/false
cupcake:x:1000:1000:,,,:/home/cupcake:/bin/bash
messagebus:x:104:109::/var/run/dbus:/bin/false
avahi:x:105:110:Avahi mDNS daemon,,,:/var/run/avahi-daemon:/bin/false
ntp:x:106:111::/home/ntp:/bin/false
sshd:x:107:65534::/var/run/sshd:/usr/sbin/nologin
statd:x:108:65534::/var/lib/nfs:/bin/false
mysql:x:109:114:MySQL Server,,,:/nonexistent:/bin/false

First off, you can discard from consideration anything ending with /nologinand anything that ends with /false as these types of user accounts are not for human users but for system agents and software pointers.

This leaves us with a much more reasonable list of candidates.

root:x:0:0:root:/root:/bin/bash
sync:x:4:65534:sync:/bin:/bin/sync
cupcake:x:1000:1000:,,,:/home/cupcake:/bin/bash

Ah ha! I enjoy my pi computers, but my dessert of choice is generally cupcakes! I do so love the icing. Exit nano WITHOUT SAVING to preserve the original contents.

In the comments below @ferrybig points out that we can also discount any account with a UUID under 1000. The UUID is the number that appears after the second colon. This tip is a really good one in that if you have more than one user, you can infer a lot about each user based on the order in which they are created, which is expressed in the sequence of their UUID's. While its not a hard and fast rule of system administration, its a good first choice to go with the lowest UUID that is higher than 1000. Admins tend to build the managing accounts before the users after all.

Now that I have the username, it's probably a good idea to blank the password for this user while I'm in the guts of the locked system. We wouldn't want to put everything back together to find our password memory is just as bad as our username memory would we?

I should note that for this example I'm showing the contents of a new install with a LAMP stack, it might have items your install doesn't. Also I renamed the default pi user to cupcake in a text editor before copying to this post. The UID for the default pi user is always 1000 and any replacement user you create will have a different UID number.

You might think that passwords are stored in a file called "passwd" but they are not. Linux programmers are sneaky that way. An 'x' in between the first and second colon indicates that a password is required for the user. Passwords are stored in the /etc/shadow file. Not all Linux systems do it this way, but Raspbian does.

Lets take a look at this file, sudo nano /etc/shadow shows us this:

root:*:17130:0:99999:7:::
daemon:*:17130:0:99999:7:::
bin:*:17130:0:99999:7:::
sys:*:17130:0:99999:7:::
sync:*:17130:0:99999:7:::
games:*:17130:0:99999:7:::
man:*:17130:0:99999:7:::
lp:*:17130:0:99999:7:::
mail:*:17130:0:99999:7:::
news:*:17130:0:99999:7:::
uucp:*:17130:0:99999:7:::
proxy:*:17130:0:99999:7:::
www-data:*:17130:0:99999:7:::
backup:*:17130:0:99999:7:::
list:*:17130:0:99999:7:::
irc:*:17130:0:99999:7:::
gnats:*:17130:0:99999:7:::
nobody:*:17130:0:99999:7:::
systemd-timesync:*:17130:0:99999:7:::
systemd-network:*:17130:0:99999:7:::
systemd-resolve:*:17130:0:99999:7:::
systemd-bus-proxy:*:17130:0:99999:7:::
cupcake:$6$JQcVeyl0$SLo4X11u6gjVAmFoHQpi.WpVo9jo4WMllykWUbEISp1:17196:0:99999:7:::
messagebus:*:17130:0:99999:7:::
avahi:*:17130:0:99999:7:::
ntp:*:17130:0:99999:7:::
sshd:*:17130:0:99999:7:::
statd:*:17130:0:99999:7:::
mysql:!:17197:0:99999:7:::

Lots of entries here, just like the /etc/passwd file before we discarded all of the /nologin and /false items. Good news is since we know cupcake is the user we are interested in this time, we don't have to discard anything to find it. The only line you are going to mess with is the line with your found user account on it.

cupcake:$6$JQcVeyl0$SLo4X11u6gj.WpVo9jo4WMllykWUbEISp1:17196:0:99999:7:::

In both /etc/passwd and /etc/shadow colons are used as separators. The actual password here is all the characters between the first and second colon, but it's encrypted. What you need to do here is remove everything between the first and second colon. When your done it should look like this:

cupcake::0:99999:7:::

Now this user will be permitted to login without a password, just hit enter at the password prompt. This is a bad practice normally, so after you login you should set a password. sudo passwd [username] and follow the prompts, be sure to replace [username] with your custom username, if your logged not into the account, it can be omitted if you are logged into the account your changing passwords for. Using sudo for this command eliminates the need to enter your current password.

If that doesn't work for you, say you can't find your username in the list or something else goes wrong, there is a last-ditch method you can use.

Any user listed in /etc/shadow with an asterisk between the first and second colon is disabled. By default, Raspbian disables the root user. remove the asterisk like the encrypted password above. This method is even more dangerous to leave in place, because you've eliminated the password on your root user. Once logged in, you'll need to create a new user with elevated permissions, reboot and login to that new user and then sudo nano /etc/shadow again and disable the root user. Leaving the root user enabled is not necessary provided you have access to sudo through your regular login. In fact it's a security risk.

Thats it, you've recovered your forgotten login and password. But where does that leave us on security? Since an accomplished hacker could bypass your digital security with physical access to your system just like I have shown here, it's probably safe enough to put the password on a post it or even writing on painter's or masking tape affixed to the case of your RPi. Especially if your RPi is in a physically secure location.

More info on the /etc/passwd and /etc/shadow files, including what all of the fields in between the colons mean, can be found here.

  • On a side note, you would not want to post password hashes of a production system on the internet, /etc/shadow isn't supposed to be -rw------- for no reason. – Ghanima Feb 1 '17 at 22:40
  • @Ghanima Very true. Very true. In my case, I was about to flash the card anyway and it made for an easy example to share. One strength RPi has is that when you fowl up an install (mysql borked on that one) its not that onerous to simply start fresh. – Sandor Dosa Feb 1 '17 at 23:32
  • 1
    It is probably preferable to view files with the cat command, for example cat /etc/passwd. This way, it just prints the contents to the screen. If the file is too large to see on one screen, you could use the less command, i.e. less /etc/passwd. – Theoremiser Feb 6 '17 at 20:29
  • 1
    Discard any user with an I'd lower than 1000 is also useful in passwd – Ferrybig Feb 8 '17 at 7:01
  • 1
    @SandorDosa I agree, but you could also use the grep command, i.e. grep -v 'nologin\|false' /etc/passwd – Theoremiser Feb 8 '17 at 20:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.