I messed up a password change for root and I am now totally locked out. There are no other user accounts on the server apart from the root account.

I am able to boot from a recovery CD and gain access to the server files. I have modified the following files:

/etc/sysconfig/selinux - to disable SELINUX
/etc/passwd - to change to blank password for root::
/etc/ssh/sshd_config - to change to MaxAuthTries 1000

Now, when I log on to root using blank password, I get:

$ ssh -o PubkeyAuthentication=no root@xxx.xxx.xxx.xxx
root@xxx.xxx.xxx.xxx's password:
Permission denied, please try again.

I think the problem is to do with the file permissions on the files I edited. I think I need to do some kind of chcon on them, but don't know what or how.

Can anyone help me please?

Editing files doesn't change the permissions, so unless you copied some other file over the existing files, permissions is not the problem. Since you can mount the filesystem from the recovery disk, you can change the password to whatever you like. Assuming you're mounting your root filesystem read/write on /mnt/sysimage, just do "chroot /mnt/sysimage" and "passwd root".

You can refer to the Red-Hat docs for more info, in particular "Procedure 25.6. Resetting the Root Password Using an Installation Disk":
https://access.redhat.com/documentat..._Root_Password

You should also re-think the wisdom of allowing root login via ssh, or any password-based login, especially if the server is internet accessible.

1 members found this post helpful.

Thanks for your solution. Because my post was delayed, I had to find the solution elsewhere that's basically same as yours and I managed to correct the problem. It was the first time something like that ever happened to me - copying and pasting of a random 32 character password that went wrong. So, I thought it was more serious than it really was.

For some reason editing the passwd file didn't work for me. So I chroot'ed and used the passwd command instead.

The server is accessible by my IP alone. So having a single user account is more convenient and less to think about.

For anyone else running into this problem, do the following, note selection of an installed shell for chroot:

mkdir /mnt/my_disk
mount /dev/dm-2 /mnt/my_disk
chroot /mnt/my_disk /bin/bash
passwd

Also note selinux had been disabled first.

The /etc/passwd file does not contain any real passwords anymore so directly editing the file does not do anything. The actual encrypted passwords are stored elsewhere.

By default ssh disables using empty passwords so that would of failed even if were successful and from the included link CentOS 7 root needs a password so you probably could not get away without one anyway.

Is that needed? I disabled it only as a random measure because I didn't know what caused the passwd file editing to fail.


Thanks. This certainly explains it.

Not absolutely required, but it saves having to remember to fix the security context else the new password won't work.