LinuxQuestions.org - Root password does not work

- Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)

- - Root password does not work (https://www.linuxquestions.org/questions/linux-newbie-8/root-password-does-not-work-4175557392/)

Root password does not work

I have a CentOS7, and I am setting up LAMP. I was able to install php and mysql, and I was trying to set the password for the mysql:

/usr/bin/mysql_secure_installation
Enter password for user root:
Error: Access denied for user 'root@localhost' (using password: YES)

I checked if I can login as root through SSH, and I got Access denied.

I am still logged in as root at the initial window, and I was able to change password with

passwd root

I entered new password twice, and I got:

passwd: all authentication tokens updated successfully.

I was trying to log in through SSH with the new password, and I was not able to. I got: Access denied again.

I am logged it as root now, and I can do whatever I want on the system.

Why does it not work? What can I do in order to get it to work?

Thanks.

please show us the output of this command from this file:

Code:

[schneidz@hyper ~]$ sudo grep ^PermitRootLogin /etc/ssh/sshd_config 

PermitRootLogin no

are you sure you want to allow anybody from anywhere to login as root ?

also, i am pretty sure that mysql has its own security database therefore the root (or any users) password is not necessarily the same as the systems password:
https://dev.mysql.com/doc/refman/5.0...rmissions.html

Didn't you just turn off root SSH access a couple of hours ago???
http://www.linuxquestions.org/questi...rt-4175557377/

Check /var/log/secure to see what it says about your login attempt.

It depends on what your setup is. For example /etc/securetty might prevent logins as root if it has been restricted. There could be PAM authentication modules you're using that restrict it or require other information. Looking at the log should give you some idea of what failed.

Code:

unix_chkpwd[xxxx]: password check failed for user (root) 

sshd[xxxx]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ryser- rhost=SOME-INFO-HERE user=root

pam_succeed_if(sshd:auth): requirement "uid >= 1000" not met by user "root"

Failed password for root from IP port PORT sshd2

Connection closed by IP [preauth]



[xxxx] - there is some numbers there, 4 digits, probably process id

User id for "root" has changed / is wrong?

Quote:

Originally Posted by AdultFoundry (Post 5441560)

Code:

unix_chkpwd[xxxx]: password check failed for user (root) 

sshd[xxxx]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ryser- rhost=SOME-INFO-HERE user=root

pam_succeed_if(sshd:auth): requirement "uid >= 1000" not met by user "root"

Failed password for root from IP port PORT sshd2

Connection closed by IP [preauth]



[xxxx] - there is some numbers there, 4 digits, probably process id

User id for "root" has changed / is wrong?

UID's over 1000 are user accounts. root UID is 0
Going off your previous post, you set PermitRootLogin to no (the default, since it is commented in the sshd_config.) So go ahead and add PermitRootLogin yes to your /etc/ssh/sshd_config. Remember to reload sshd afterwards (systemctl reload sshd).

Remember, this is BAD SECURITY PRACTICE. The recommendation is to just make a user account with ssh and sudo rights.

Quote:

Originally Posted by Demosa (Post 5441562)

The recommendation is just to shut off root ssh access, this has nothing to do with sudo. There is no need to have sudo installed or configured if you have root ssh access shut off, it just means you need to ssh into a regular user and then use "su" to elevate your privileges to root.

BTW - the default for RHEL/CentOS is for PermitRootLogin to be set to yes, it has to be explicitly shut off by the user.

I changed all the values to the default ones, so this line is set to:

Code:

#PermitRootLogin yes

If I am correct, the default is PermitRootLogin yes, so the uncommended version should work.

I addded

Code:

AllowUsers UsernameThatIcreatedHere

as the last line. Everythig else should be as the default / original. It still does not seem to be working though.

I noticed the following lines, look like default settings:

Code:

PasswordAuthentication yes

PasswordAuthentication no

UsePAM yes

Again, I realize that this is very basic, and it is like talking about the most obvious things, but it does not seem to be working as it should, still...

Quote:

Originally Posted by AdultFoundry (Post 5441566)

I addded

Code:

AllowUsers UsernameThatIcreatedHere

as the last line. Everythig else should be as the default / original. It still does not seem to be working though.

I noticed the following lines, look like default settings:

Code:

PasswordAuthentication yes

PasswordAuthentication no

UsePAM yes

Again, I realize that this is very basic, and it is like talking about the most obvious things, but it does not seem to be working as it should, still...

Remove that AllowUsers line, it's unnecessary

You really need to stop mucking about with your sshd config, your PasswordAuthentication lines are NOT the default and could really screw things up. The PasswordAuthentication section should look like the following:

Code:

# To disable tunneled clear text passwords, change to no here!

#PasswordAuthentication yes

#PermitEmptyPasswords no

PasswordAuthentication yes

The default for PAM is yes:

Code:

# Set this to 'yes' to enable PAM authentication, account processing,

# and session processing. If this is enabled, PAM authentication will

# be allowed through the ChallengeResponseAuthentication and

# PasswordAuthentication.  Depending on your PAM configuration,

# PAM authentication via ChallengeResponseAuthentication may bypass

# the setting of "PermitRootLogin without-password".

# If you just want the PAM account and session checks to run without

# PAM authentication, then enable this but set PasswordAuthentication

# and ChallengeResponseAuthentication to 'no'.

# WARNING: 'UsePAM no' is not supported in Red Hat Enterprise Linux and may cause several

# problems.

#UsePAM no

UsePAM yes

Do you have a backup of this file before you started touching it at all? If not, I recommend setting up a CentOS 7 VM on your local machine and grabbing the default sshd_config off of that. Once you're back to the default config, change PermitRootLogin to no, uncomment it, and that's IT, leave the rest of the entire file alone until you know what you're doing. And, as implied by that change, once you make it you will no longer be able to ssh into the system as root, that's the point, you shouldn't be surprised when it won't let you do it. It is not necessary to make ANY other changes to this file unless you have some niche requirements.

It is still unclear whether your original mysql error is even referring to regular user accounts or special mysql accounts, as schneidz mentioned earlier.

Quote:

Originally Posted by AdultFoundry (Post 5441566)

I changed all the values to the default ones, so this line is set to:

Code:

#PermitRootLogin yes

...

the # means it is commented out. try removing the # and restart sshd and hope for the best.

Quote:

Originally Posted by schneidz (Post 5441573)

the # means it is commented out. try removing the # and restart sshd and hope for the best.

I just tested both with systemctl reload sshd.service

#PermitRootLogin yes

and

PermitRootLogin yes

Neither of these work. Access denied, when I try to open another ssh connection through user "root". It would be good to fix this, as I would like to turn off the pc...

Edit:
@Demosa
"Remember, this is BAD SECURITY PRACTICE. The recommendation is to just make a user account with ssh and sudo rights."

This part I know very good. I read it in like 80 of the books that I read (Linux, I would say the best that are out there now). The best for Apache seems to be "Pro Apache, 3rd" by the way. There is a new one coming out from O'Reilly I think, and all the other ones that are out there are old (I still read them though).

# # #
In general, working on Linux does not seem to very hard, as people may be suggesting, I think. It is all described on the Internet, in multiple places, and everything can be found through google.com (or other search engines). Like I said, I went over like 15 books (it took me 3 months) and this background knowledge is very good. Using it is the best learning now, but again, it does not seem to be that hard (some people were saying, it takes 2-3 years to learn it, but this was probably with things like awk, perl, advanced scripting, I dont remember all these names now, but along these lines). I personally need it only for web server / email / ftp.

Quote:

Originally Posted by AdultFoundry (Post 5441575)

That's because for some reason you shut PasswordAuthentication off globally, at least according to your last post...which means unless you've set up key-based authentication you're now locked out of the system on all accounts (hopefully your existing sessions don't time out).

Quote:

Originally Posted by suicidaleggroll (Post 5441580)

That's because for some reason you shut PasswordAuthentication off globally, at least according to your last post...

So where could I go from here?

Edit: I did not notice your last post, I will go over it now. And yes, I did not make a backup. I read about it in some place before...

I had this part wrong:

Code:

# To disable tunneled clear text passwords, change to no here!

#PasswordAuthentication yes

#PermitEmptyPasswords no

PasswordAuthentication yes

I had it set to PasswordAuthentication No, and it did not work :)

Thanks again for the answers, I know it was all very basic, at this point.

Quote:

Originally Posted by AdultFoundry (Post 5441581)

So where could I go from here?

Change PasswordAuthentication back to yes, restart sshd, hope you can get in, and then get a default sshd_config to replace the one you've been messing with to restore normal functionality.

A VPS is not the place to be experimenting with these kinds of things. You were one internet hiccup away from locking yourself out of your VPS permanently.

Set up a VM on your local system and experiment there. Use snapshots so when you screw something up irrecoverably (and you will, multiple times) you can just restore from it and use those lessons to hopefully not screw up the VPS.