We have setup our account policies in PAM to follow the RHEL7 STIG guidelines http://rhel7stig.readthedocs.io/en/latest/. We do have some service accounts where their passwords are empty and use SSH keys to login. After the 60 days the service accounts password expire and get disabled. This is not the behavior I was expecting for a passwordless account, I did not think the password expiration would have applied to passwordless accounts. How do I tell PAM not to expire passwordless accounts?
In login.defs
PASS_MIN_DAYS 1
PASS_MAX_DAYS 60
PASS_WARN_AGE 7
FAIL_DELAY 4
In /etc/default/useradd
INACTIVE=0
Since the system doesn't care if these accounts have a password or not. You'll have to set PASS_MAX_DAYS to 99999 or what ever seem appropriate for these accounts.
Looks like I need to create these accounts as system accounts. From the useradd man page...
System users will be created with no aging information in /etc/shadow - https://linux.die.net/man/8/useradd
Example command.
useradd testuser --system
If you're using Ansible you can specify system in the user module.
- user:
name: testuser
group: testuser
system: yes
The result is visible in /etc/shadow. Notice no password max age entry for the testuser.
[root#localhost ~]# useradd testuser --system
[root#localhost ~]# grep testuser /etc/shadow
testuser:!!:17417::::::
[root#localhost ~]# grep ryan /etc/shadow
ryan:*:18976:1:60:7:0::
PAM solution offers a secure, streamlined way to authorize and monitor
all privileged users for all relevant systems.
IT teams commonly share root, Windows Administrator, and many other privileged credentials for convenience so workloads and duties can be seamlessly shared as needed. Now, with multiple people sharing the same account password, creates security, auditability, and compliance issues. Privileged accounts and credentials may be managed differently across various organizational silos, leading to inconsistent enforcement of best practices. Applications and service accounts frequently possess excessive privileged access rights by default, and also suffer from other serious security deficiencies.
The solution can be: "UsePAM no"
The solution can be: Set the users password to never expire
You might not want to change your PAM or sshd_config for compliance
reasons.
You might be using PasswordAuthentication no in sshd_config
You might have randomized passwords.
You might even have implemented CIS compliance.
Still if your users get the prompt, then root can tweak the password changed date:
for user in `grep ":x:[0-9]\{4\}" /etc/passwd|cut -d: -f1`; do chage -d today $user;
Attaching a few references:
https://access.redhat.com/solutions/5447861
https://documentation.suse.com/sles/15-SP2/html/SLES-all/sec-sec-user-management.html
Final Thoughts:
I believe that we need to keep our accounts authenticated to avoid any 3rd party or other irrelevant users accessing our data & information for the reason, that we may have confidential data that we may want to protect from diverse eyes that are on the web.
Also, you may take a look at this answer, if you need an another perspective of my answer (https://stackoverflow.com/a/46120833/18154805)
Related
I have a requirement to validate if a given user can login to a machine. I don't know their password, but the script can elevate to root using sudo. All the users are AD accounts using SSSD.
Everything I've found just validates if the user is valid or not, such as using
id -u. Doing sudo -lu doesn't work if the user has never logged in before and only shows their sudo permissions. I've also tried using ldapsearch, but that only queries the AD server to see if they have the correct profiles, but not necessarily on that server.
Create in the Domain a group with the users you want to allow in the machine and use it in the key simple_allow_groups explained below.
In the /etc/sssd/sssd.conf Add/Modify the following keys:
access_provider = simple # This will allow you to control who can log in the computer using the simple_allow_groups.
simple_allow_groups = groupname1, groupname2 # Domain groupnames allow you to limit the log on permission for just the members of the groups in this option.
Edit the sudoers (using visudo) and add:
%groupname1 ALL=(ALL) NOPASSWD: ALL
This will allow the user to run any command. If you want to limit the commands allowed, see the examples in the sudoers file.
Our Perforce server is set to security level 0, meaning that most users don't require passwords. This is fine (and necessary for our legacy tools). However I recently discovered to my horror that some admin user accounts don't have passwords set. This is obviously very bad.
How can we configure Perforce to require passwords for superuser accounts, but not for regular accounts?
I seem to remember this was the case by default, but someone seems to have defeated it, and now I can't find any mention of it in the Perforce manual.
We cannot change the server to require passwords from all users without breaking the whole company. Setting the server security level to >1 globally is not a workable answer.
Nope, this was never a feature.
My solution to this has historically been to have a script that tries to run a command as each user. In your case you want to only look at users with admin-level permissions, so have the script run a command that only admins should be able to run:
p4 -u $USER protect -o
If this succeeds (despite the lack of any password being provided), deal with them as you like. In my case I wasn't targeting admin users specifically so I just had my script set a random password and email it to them with instructions for changing it.
Given your scenario, my recommendation would be to just revoke admin access, since someone who's not savvy enough to secure their own account probably shouldn't be trusted with the ability to grant access to others, install triggers, permanently delete data, etc...
On many varieties of Linux PostgreSQL runs under a separate user account, so you have to do:
sudo su - postgres
to get any work done. That's all well and good if you just want to type SQL in manually, but what if you have a migration written in a programming language (in my case, Node/Knex)?
Is the common practice to somehow make the code aware of the user situation (ie. write something equivalent to sudo su - postgres in to my code)?
Or, is it to run all of my code as the DB user (even though that would mean giving my DB user permissions on my non-DB user's home folder)?
Or, is it to make my normal user have Postgres access (in which case why does Linux even bother setting Postgres up on a separate user)?
Or, is there some other approach I'm missing?
P.S. I realize this is somewhat a systems administration question, but I posted here rather than super user because it's specifically about running programmer-written code (which just happens to alter a database).
You are conflating three separate user accounts.
First there is the OS account under which the postgresql daemon runs. As you say in most Linux distros this would be a separate user used only for this purpose, often named postgres. This is to prevent other users on the system from accessing the postgresql data files and other resources, and also to limit the damage that could be done by someone who hacked their way into the database.
Then there is the user account which the client program, such as psql or your migration tool might run under.
Finally there is the postgresql user account. Postgresql has it's own user account system to manage the permissions of users within the databases that it administrates, unconnected to the OS user account system.
The one are of overlap between the OS accounts and the postgresql database accounts is that the psql command line tool will connect to the database using a user name the same as the OS user running the tool if you do not specify a user on the command line. For example, if I connect with this:
psql mydatabase
then it will attempt to connect with the user harmic, my Linux user account, but if I use this:
psql -U postgres mydatabase
then it will connect with the user postgres, which is the default administrator account.
Another related aspect is the authentication method. Most likely, if you try the above command on your machine, you would get an error. This is due to the allowed authentication methods, which are configured in the file pg_hba.conf. This file configures allowed authentication methods that specific users can use when connecting to specific databases from specific hosts. The postgres user is normally only allowed to connect from within the same host, using ident as the authentication method, which means identify the user based on the OS user running the command.
This explains why you have been using sudo su - postgres to switch to the postgres user: most likely in your current configuration that is the only way to access this account.
OK, this probably all sounds rather complex. To simplify things, here are my recommendations for best practices in this area:
Do not mess with the OS account used to run the database backend. It is not needed and would weaken security.
Create a separate database account for administrating the application's database(s). Use this account rather than the postgres account for migration scripts and the like. The reason for this is that the postgres account has full permissions over all databases on the server, while you can grant your admin user only the permissions it needs, and only to the database(s) the application controls (not any other databases that might be there). See: CREATE USER SQL command.
Update the pg_hba.conf file to specify the authentication mode that will be used to authenticate this user. See Client Authentication in the manual. md5 with a suitably strong password might be a good choice.
Update your migration tool to use this new user. The user (and password if using passwords) would be supplied via the connection string or connection parameters supplied when connecting to the database. Likewise when connecting with psql specify the user name with the -U option.
Note that there is no need to use sudo su - or even to have an OS account with the same name as the admin user.
When I create a user on Gitlab, it creates a regular user on linux and it can login using a regular SSH protocol with same password an user.
How can I disable the SSH login using SSH to desired users? All my server is exposed to that users.
Thank you
Edit the sshd_config file adding this line
DenyUsers username1 username2 username3 username4
DenyUsers
separated by spaces. Login is disallowed for user names that
match one of the patterns. â*â and â?â can be used as wildcards
in the patterns. Only user names are valid; a numerical user ID
is not recognized. By default, login is allowed for all users.
If the pattern takes the form USER#HOST then USER and HOST are
separately checked, restricting logins to particular users from
particular hosts.
Read more: http://linuxpoison.blogspot.com/2008/08/how-to-deny-ssh-access-for-certain-user.html#ixzz3QkT71bsV
In case you need more than just the login, you can now block SSH as a all:
See GitLab 15.1 (June 2022)
Block Git access protocols at group level
To improve security, you can now block Git access protocols that you don’t use at the group level.
This is similar to the GitLab administrator setting, but can now be set per
group.
By default, both HTTP(S) and SSH are enabled.
In your group’s Settings > General > Permissions, scroll to Enable git access protocols and remove any protocols you don’t use.
See Documentation and Issue.
I have a sudo account (not root) on several CentOS servers. We would like to share the cluster with other uses who do not have an account for research purpose. (By share I mean users can reserve a time slot to use the cluster exclusively.) But setup an account in the OS for each user is too annoying. Is there a good way to grant them authority to read/write/execute their own files during a certain period of time? I am thinking something like temporary username and password that they can use to login through some interface (like a webserver) I offered. And the username and password will expire after when their reservation. Any idea?
You can share your unix user account among several users, by using SSH key authentication.
In a nutshell, each user generates a public/private key combination. The allowed public keys are then listed in the following file on the shared unix acount:
$HOME/.ssh/authorized_keys
I'm not aware of a mechanism to control when users are allowed to login. Presumably one could have a cronjob that swaps different versions of the authorized_keys file, dependent on the time of day. (Seems like over engineering the solution, users can easily over-ride this kind of restriction).
Articles:
http://wiki.centos.org/HowTos/Network/SecuringSSH
http://www.ualberta.ca/CNS/RESEARCH/LinuxClusters/pka-putty.html