Pam checking UID => 1000, How to disable
Re: Pam checking UID => 1000, How to disable
There are two things happening in this thread.
1. OP is unable to login as root.
2. OP is specifically asking how to disable the pam UID-checking.
I irks me that everyone jumps on the band wagon of refusing to address 2.
I understand that in OP's case the UID-checking is not the real problem. But it is not so mildly annoying when you're me, with legitimate non-root users with sub-1000 uids and you find this perfectly labeled topic containing none of the information you need.
I've nuked the uid-check from the pam-files, but it keep coming back as there is some machinery (authconfig?) regenerating the files. If we go back to the original question and leave our prejudices about what's "right" at the door; how do you tweak/remove the uid>1000-limit (in a maintainable/upgradable way)?
1. OP is unable to login as root.
2. OP is specifically asking how to disable the pam UID-checking.
I irks me that everyone jumps on the band wagon of refusing to address 2.
I understand that in OP's case the UID-checking is not the real problem. But it is not so mildly annoying when you're me, with legitimate non-root users with sub-1000 uids and you find this perfectly labeled topic containing none of the information you need.
I've nuked the uid-check from the pam-files, but it keep coming back as there is some machinery (authconfig?) regenerating the files. If we go back to the original question and leave our prejudices about what's "right" at the door; how do you tweak/remove the uid>1000-limit (in a maintainable/upgradable way)?
Re: Pam checking UID => 1000, How to disable
As I've posted many times before, I have normal users with uids < 1000 and I do not have this problem. It just works.
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Re: Pam checking UID => 1000, How to disable
which you have stated in this thread, is not the same asTrevorH wrote:I can still ssh as root
.TrevorH wrote:I have normal users with uids < 1000
Also, since login works when I remove the pam check for the uid, but my users get upset (with me) when the system regenerates the line I'm fairly confident that i have pinpointed the issue correctly. That your system happen to work is of limited value to me.
I've upgraded into this limit before on ubuntu (12.04->14.04 I think), but looking at my ubuntu systems today the limit seem to have been removed (with 14.04->16.04?). Maybe you've updated past it on your systems as I have on Ubuntu?
Re: Pam checking UID => 1000, How to disable
No
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Re: Pam checking UID => 1000, How to disable
Painted myself into a corner here, but I can recognise when I'm in the wrong. I spun up a vm to replicate the issue from my other now unavailable system.
On a fresh install with local accounts I'm unable to reproduce.
Pam still seem to be configured to require uid>=1000:
One user over, and one user under:
Not what I expected, but both can login:
This is not how my other machines work.
On a fresh install with local accounts I'm unable to reproduce.
Pam still seem to be configured to require uid>=1000:
Code: Select all
[root@yolow ~]# grep -sIRw uid /etc/pam.d | grep requisite
/etc/pam.d/system-auth-ac:auth requisite pam_succeed_if.so uid >= 1000 quiet_success
/etc/pam.d/system-auth:auth requisite pam_succeed_if.so uid >= 1000 quiet_success
/etc/pam.d/password-auth-ac:auth requisite pam_succeed_if.so uid >= 1000 quiet_success
/etc/pam.d/password-auth:auth requisite pam_succeed_if.so uid >= 1000 quiet_success
Code: Select all
[root@yolow ~]# ll /home
total 0
drwx------. 2 user0 user0 62 Mar 9 20:53 user0
drwx------. 2 user1 user1 83 Mar 9 20:56 user1
[root@yolow ~]# grep user[01] /etc/passwd /etc/shadow /etc/group
/etc/passwd:user0:x:666:666::/home/user0:/bin/bash
/etc/passwd:user1:x:1000:1000::/home/user1:/bin/bash
/etc/shadow:user0:$6$gxzb1FcD$61pbUg23j01uCbyYZ3CBWRpniXPYqzmY7ULfmMOpLGoZXwfwDHv9DJckEktcwglrlIJVmc9Y539QdKWLrrgPD0:17234:0:99999:7:::
/etc/shadow:user1:$6$l53e4Xw3$LqwjKMDRdvxb5WmI2Qn5ywfnu6L6zz1igZY687V2aHyg2Nl0KfrdCeCoFOb51Fv7f1flu4hvJgTVgJElvTtl81:17234:0:99999:7:::
/etc/group:user0:x:666:
/etc/group:user1:x:1000:
Code: Select all
➜ ~ ssh 172.16.0.133 -l root
root@172.16.0.133's password:
Last login: Thu Mar 9 20:56:56 2017 from laptop.azzid.home
[root@yolow ~]# logout
Connection to 172.16.0.133 closed.
➜ ~ ssh 172.16.0.133 -l user1
user1@172.16.0.133's password:
Last login: Thu Mar 9 20:56:25 2017 from laptop.azzid.home
[user1@yolow ~]$ logout
Connection to 172.16.0.133 closed.
➜ ~ ssh 172.16.0.133 -l user0
user0@172.16.0.133's password:
Last login: Thu Mar 9 20:56:21 2017 from laptop.azzid.home
[user0@yolow ~]$ logout
Connection to 172.16.0.133 closed.
Re: Pam checking UID => 1000, How to disable
It should be noted however, that as OP suspected, authconfig does read login.defs:
Code: Select all
[root@yolow ~]# grep UID_MIN /etc/login.defs
UID_MIN 1000
SYS_UID_MIN 201
[root@yolow ~]# authconfig --updateall
[root@yolow ~]# grep uid /etc/pam.d/password-auth
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
account sufficient pam_succeed_if.so uid < 1000 quiet
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
[root@yolow ~]# vim /etc/login.defs
[root@yolow ~]# authconfig --updateall
[root@yolow ~]# grep uid /etc/pam.d/password-auth
auth requisite pam_succeed_if.so uid >= 500 quiet_success
account sufficient pam_succeed_if.so uid < 500 quiet
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
Re: Pam checking UID => 1000, How to disable
What is the uid check for?
If I read that right, the uid-check will only run if pam_unix.so fails, i.e. login will not succeed regardless. Only difference I can think of the line making is changing how the "login denied" get logged. If user has uid<1000 pam_deny.so will run, if uid>=1000 it will not, but pam_deny.so will block instead. Both lines will only produce (albeit different) log lines stating that login failed.
Or am I not understanding how it works?
Code: Select all
[root@yolow pam.d]# grep ^auth login system-auth postlogin
login:auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so
login:auth substack system-auth
login:auth include postlogin
system-auth:auth required pam_env.so
system-auth:auth sufficient pam_unix.so nullok try_first_pass
system-auth:auth requisite pam_succeed_if.so uid >= 1000 quiet_success
system-auth:auth required pam_deny.so
Or am I not understanding how it works?
Last edited by azzid on 2017/03/10 20:18:19, edited 1 time in total.
Re: Pam checking UID => 1000, How to disable
I can probably finish off my ramblings with the following.
Getting back to the malfunctioning system I found the password-auth file to look like this:
Since my sub-1000 user is ldap authed it makes perfect sense that pam blocks them.
Getting back to the malfunctioning system I found the password-auth file to look like this:
Code: Select all
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so
-
- Posts: 2019
- Joined: 2015/02/17 15:14:33
- Location: Bulgaria
- Contact:
Re: Pam checking UID => 1000, How to disable
Let me share my opinion in this thread as it seems to not resolve this issue.
1.The problem is not in the UID check.It's probably in the rules above.I support Trevor's opinion not to treat the symptoms, but to cure the disease.
I suspect an issue probably in ssh/selinux which leads the rules above to fail.root user is not supposed to go so far below.Thus please try the following:
a)Check if it's selinux -use setenforce
b)Check the permissions and ownership of /root, /root/.ssh and it's contents (ls -lZ) will be sufficient.
2.RHEL/CentOS7 fully supports permanent changes to authconfig's files.(Check redhat's guide for locking users after N failed logins)
If none of the previous do the job,then just copy the /etc/pam.d/ from a freshly installed VM.
Edit:What is the output when trying to connect?
Paste the output of:
In order to rule out any issues with bash -change root's shell (probably ksh could do the job).
Even if you find the reason without our sugestions- post it here for future refference.
1.The problem is not in the UID check.It's probably in the rules above.I support Trevor's opinion not to treat the symptoms, but to cure the disease.
I suspect an issue probably in ssh/selinux which leads the rules above to fail.root user is not supposed to go so far below.Thus please try the following:
a)Check if it's selinux -use setenforce
b)Check the permissions and ownership of /root, /root/.ssh and it's contents (ls -lZ) will be sufficient.
2.RHEL/CentOS7 fully supports permanent changes to authconfig's files.(Check redhat's guide for locking users after N failed logins)
If none of the previous do the job,then just copy the /etc/pam.d/ from a freshly installed VM.
Edit:What is the output when trying to connect?
Paste the output of:
Code: Select all
ssh -vvv root@ip_of_server_that_complains_about_bash
Even if you find the reason without our sugestions- post it here for future refference.
Re: Pam checking UID => 1000, How to disable
Who is "you"? me or OP?hunter86_bg wrote:if you find the reason without our sugestions- post it here for future refference.
My problem was solved with tweaking the limit in /etc/login.defs and running authconfig --update.
In my case, verified and done, the problem really was the user uid.
The proper solution for me is to have the users change uids.
Until that can happen I'll just have the limit set lower.