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

[chrischevy]

I have a brand new system (15.0.17.34) and it seems like I can’t login with root in ssh. I can login on the console without issue.

I get the following message in the secure log:
pam_succeed_if(sshd:auth): requirement "uid >= 1000" not met by user "root"

Did something change ? It’s the first time I see this. I know that I can Google it and find a way to fix it but I would prefer not messing up with the system if this behavior is the new default configuration.

[sorvani (Jared Busch)]

You never want to have root ssh available anyway.

So if this is a change, it is a good change. I spun up a system yesterday but never tried to SSH as root before disabling it myself as part of my standard process.

Log in to the console as root and make a new account

# Create a user
useradd chrischevy
# Set the user password
passwd chrischevy
# Make the user a member of wheel so they can sudo
gpasswd -a chrischevy wheel
# Make the user a member of asterisk so you can asterisk -r without sudo
gpasswd -a chrischevy asterisk

[chrischevy]

Thank you for your answer sorvani. I know that root SSH access is bad, but I only allow SSH from our fixed IP (I block it using both the cloud provider’s firewall and FreePBX’s firewall).

Having root SSH out of the box has always been very usefull for me. Quickly connecting with Putty or WinSCP (to transfer audio files around).

I’d like to know if this access will now be blocked by default (following a certain update let’s say). If so, I will have to create new users on all the systems I manage.

[dicko]

I would like to point out that the biggest exposure is not simply allowing root access but allowing ‘password’ access on port 22 to anyone. (you will always have every one and their dog hammering at port 22 unless you have an up line firewall filtering it.) watch the auth logs and see root, admin, freepbx, wordpress, phpadmin , webmin and a plethora of other previously compromised account passwords.

Allow public key authentication only on a ‘less known’ port , protect your private key and regenerate that key regularly.

If you ever get that public key compromised, you have a way bigger problem which you need to immediately fix , otherwise you are only marginally protected by a one more need for “switch user” to root step.

[dicko]

That is basically suggesting that ‘PermitRootLogin no’ is set in /etc/ssh/sshd_config

That coupled with ‘PubkeyAuthentication yes’ and a valid entry in .ssh/authorized_keys for the relevant user should fix that.

Were you happy with nopassword but pubkey only for root , then allow rootlogin after adding any root pubkey you trust.

[chrischevy]

Once again, thanks for all the information. I will review my work method.

Just so you know: it seems like my password was the problem.
When I was using it in the console, I could login.
When I was using it with putty, it didn’t work.

There was a hashtag (#) at the end of my password. Just for the sake of testing, I replaced it with an exclamation mark (!) and BAM, it worked !

It’s not a keyboard issue, as I tried typing my password in the “username” field to make sure it was coming out ok in putty.

Oh well, it doesn’t make any sense but it works, I have no clue why…