Sometime by accident you may delete /etc/shadow file. If you boot into single user mode, system will ask root password for maintenance, and just imagine you do not have a backup of /etc/shadow file. How do you fix such problem in a production environment where time is critical factor? I will explain how to recover deleted /etc/shadow file in five easy steps. It will take around 10 min. to fix the problem.
Well all it started when one of our client accidentally deleted /etc/shadow file from co-located Debian Linux server. As a result, all account login disabled. However, ftp was working fine because proftpd was build using MySQL database for authentication and quota management.
Boot server into single user mode
1) Reboot server
2) Next, you will see grub-boot loader screen. Select Recovery mode the version of the kernel that you wish to boot and type e for edit. Select the line that starts with kernel and type e to edit the line.
3) Go to the end of the line and type init=/bin/bash as a separate one word (press the spacebar and then type init=/bin/bash). Press enter key to exit edit mode.
init=/bin/bash

4) Back at the GRUB screen, type b to boot into single user mode. This causes the system to boot the kernel and run /bin/bash instead of its standard init. This will allow us gain root privileges (w/o password) and a root shell.
Make sure you can access system partition(s)
1) Mount partitions in read write mode
Since / is currently mounted read-only and many disk partitions have not been mounted yet, you must do the following to have a reasonably functioning system.
# mount -rw -o remount /
Do not forget to (re)mount your rest of all your partitions in read/write (rw) mode such as /usr /var etc (if any)
Rebuild /etc/shadow file from /etc/passwd
1) You need to use pwconv command; it creates /etc/shadow from /etc/passwd and an optionally existing shadow.
# pwconv
2) Use passwd command to change root user password:
# passwd
Note you may need to type same password twice with passwd command. If you have an admin account, then setup password for that account. On most production, servers direct root login is disabled. In our situation, admin was the only account allowed to use su and sudo command.
# passwd admin
3) Now root and admin accounts are ready to go in multi-user mode. Reboot the system in full multiuser mode:
# sync
# reboot
Step # 4 Block all non-root login
Block all non-root (normal) users until we fix all password related problems. Since rest of account do not have any password, it is necessary to prevent non-root users from logging into the system. You need to create /etc/nologin file, it will allow access only to root. Other users will be shown the contents of this file and their logins will denied (refused)
1) Login as root user (terminal login only)
2) Create /etc/nologin file
cat > /etc/nologin
System is down due to temporary problem. We will restore your access
within 30 minutes time. If you have any questions please contact tech
support at XXX-XXXX or techsupport@mycorp.com
Update all users password in batch mode
1) Create random password for each non-root user using chpasswd utility. It update passwords in batch mode. chpasswd reads a list of user name and password pairs from file and uses this information to update a group of existing users. Each line is of the format:
user_name:password
Remember by default the supplied password must be in clear-text format. This command is intended to be used in a large system environment where many accounts are created at a single time or in emergency like this. First, we need to find out all non-root accounts using awk command:
awk -F: '{ if ( $3 >1000 ) print $1}' /etc/passwd > /root/tmp.pass
Make sure /root/tmp.pass file contains non-root usernames only.
2) Create random password with pwgen
By default, pwgen utility is not installed so with the help of apt-get install it:
# apt-get install pwgen
The pwgen program generates passwords which are designed to be easily memorized by humans, while being as secure as possible. For example following command print the generated password:
# pwgen -1 -n 8
Download complete working script that updates user password in batch mode. Execute script batch-update-password.sh:
# chmod +x batch-update-password.sh
# ./batch-update-password.sh
Now update user passwords with chpasswd, by default script creates file in /root/batch.passwd file:
# chpasswd
3) Email new password to server admin or all end users. You can write a script to email password end users.
4) Your system is ready to accept login, just remove /etc/nologin file:
# rm /etc/nologin
There are other ways to recover /etc/shadow file, depend upon your setup and backup frequency you can use any one of the following method too:
- By default, your /etc/passwd and /etc/shadow file are backup to /var/backups under Debian Linux. You can just copy shadow.bak file after step # 1:
# cp /var/backups/shadow.bak /etc/shadow
- Some time /etc/shadow- file can be use to replace /etc/shadow
- If you have a backup of /etc/shadow on tape or cdrom then you can copy back /etc/shadow file after step #1.
I guess it explains the important of regular backup of both data and key files.
See also:
- Understanding UNIX/Linux file system
- Linux : How to delete file securely
- Linux/UNIX: Recover deleted files


{ 14 comments… read them below or add one }
What I would do instead of generating all new passwords is simply restore /etc/shadow from the nightly backup tape. This procedure would be good if you aren’t doing backups, but if you aren’t, shame on you!
You should block user logins *before* you reboot in multiuser mode. That is, swap steps #3 and #4.
And where did you recover the deleted shadow?
>And where did you recover the deleted shadow?
Read Step # 3 : Rebuild /etc/shadow file from /etc/passwd, as soon as you type command pwconv, your file will be back.
# pwconv
>You should block user logins *before* you reboot in multiuser mode. That is, swap steps #3 and #4.
I guess you can go both ways
Use LDAP for system authentication, and you don’t need to recover the shadow file …
I’m aware of OpenLDAP and other directory authentication services. On the other hand they are good for big setup (more than 3-4 servers). This was customers managed single server. Therefore, I cannot go and suggest them
thanks for your suggestion.
You’re regenerating /etc/shadow, not recovering it from a delete. You don’t (becuase you can’t) recover user passwords.
And, just as a question, which is the probability of losing only /etc/shadow and not your whole disk?
And a question 2: if a user as root deleted /etc/shadow, which is the probability that he do
dd if=/dev/zero of=/dev/sda??
>Alejandro said…
>You’re regenerating /etc/shadow, not recovering it from a delete. You don’t (becuase you can’t) recover user passwords. And, just as a question, which is the probability of losing only /etc/shadow and not your whole disk?
Yup it is regenerating or it creates /etc/shadow from /etc/passwd and an optionally existing shadow. As I said earlier, file deleted by mistake.
>And a question 2: if a user as root deleted /etc/shadow, which is the probability that he do dd if=/dev/zero of=/dev/sda??
I am sorry but I am not getting your point here. Sure root can run dd and destroy entire disk. That is what I said at the bottom, “I guess it explains the important of regular backup of both data and key files.”. Since this server was 3rd party hosted in our IDC. It is not managed by us. Customer itself managing the server and they did not have a backup copy of /etc/shadow file; all they got was backup of mysql and ftp server. Moreover, ftpserver was working fine because proftpd was build using MySQL database for authentication and quota management. Therefore, I had to restore /etc/shadow file
I hope this clears picture.
Guys,
I have different problem. I accidentally deleted /etc/passwd file. Now i am not able to login to any user mode. My operating system is SCO Unix. Please Help me.
regards,
Rajesh
If the file /etc/shadow is deleted, but the computer is still running and you still have root access, it might be possible to regenerate it from memory similar to the following approach:
cat /proc/kcore | strings | egrep "^([^:]*:){8}[^:]*$” > /tmp/kcore-dump
Now you have a file which might include the contents of the deleted /etc/shadow. Now you have to take a text editor and extract the correct lines. Special care has to be taken because the contents might be incomplete or even wrong.
I followed above doc
and ran :
1. Rebooted
2. Edit Recovery Mode : with init=/bin/bash
3. mount -rw -o remount /
4. Edited /etc/passwd file(Surprisingly nano editor was working but vi dint)
5. Moved passwd- to passwd and moved shadow- to shadow.
6. Forcibly rebooted.
Now it seems to work. But it displays:
I have no name!@micex:~$
Why it is displaying so??
I dint see any pwconv command on my system now.
Can Anyone please help me with this long stucked issue?
Thank you very much! Very helpful.
I would however put the last bit about recovering from your backup *before* the batch generation. For smaller system it is seems alot easier to simple cp back the shadow file.
thanks again!