Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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
Last edited by schneidz; 10-28-2015 at 02:31 PM.
Reason: added bit about mysql password and link.
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.
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
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.
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.
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.
Last edited by suicidaleggroll; 10-28-2015 at 02:58 PM.
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...
Last edited by AdultFoundry; 10-28-2015 at 03:01 PM.
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.
Last edited by suicidaleggroll; 10-28-2015 at 03:16 PM.
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.
Last edited by AdultFoundry; 10-28-2015 at 03:22 PM.
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...
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).
Last edited by suicidaleggroll; 10-28-2015 at 03:25 PM.
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.
Last edited by suicidaleggroll; 10-28-2015 at 03:32 PM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.