bash scripting on red hat help needed

[bornerwave]

hi guys, i am currently creating a bash script on red hat RHELv6 to lock user accounts(one user as specified by the admin who will be using this script)

I am currently confused between using usermod -L or passwd -l(small L)... which to use? whats the difference?

 

[davidktw]

hi guys, i am currently creating a bash script on red hat RHELv6 to lock user accounts(one user as specified by the admin who will be using this script)

I am currently confused between using usermod -L or passwd -l(small L)... which to use? whats the difference?

You answer can be easily found by reading the manual

man usermod
man passwd

Learn how to read the unix manual. That is why they are there and so easily accessible. There are normally multiple ways to do that same thing in unix. The main reason for your scenario is because these are just tools. Ultimately partial control of local unix users can found in /etc/passwd file

 

[bornerwave]

You answer can be easily found by reading the manual

man usermod
man passwd

Learn how to read the unix manual. That is why they are there and so easily accessible. There are normally multiple ways to do that same thing in unix. The main reason for your scenario is because these are just tools. Ultimately partial control of local unix users can found in /etc/passwd file

i did check man, i even went to computerhope to check for the definition of usermod and passwd and asked my seniors... in the end i used usermod -L and usermod -e... they said passwd can still enable someone to login using other means?

 

[davidktw]

i did check man, i even went to computerhope to check for the definition of usermod and passwd and asked my seniors... in the end i used usermod -L and usermod -e... they said passwd can still enable someone to login using other means?

If you already lock the account, how do that someone even get into the unix system to even run any commands including your "passwd". Of course you must make sure the user is thoroughly removed from the system first.

First you must prevent any possibility of the intended user has established public key authentication to login into the system. Go to the user home directory and rename and .ssh directory to .ssh.old

Then lock him out of the system, using "pkill -u <USERNAME>"

# mv ~/USERNAME/.ssh{,.old}; passwd -l USERNAME; pkill -u USERNAME

If the user still have other avenues to enter the system such as FTP or WEBDAV or other methods, you will need to take care of those separately.

 

[bornerwave]

If you already lock the account, how do that someone even get into the unix system to even run any commands including your "passwd". Of course you must make sure the user is thoroughly removed from the system first.

First you must prevent any possibility of the intended user has established public key authentication to login into the system. Go to the user home directory and rename and .ssh directory to .ssh.old

Then lock him out of the system, using "pkill -u <USERNAME>"

# mv ~/USERNAME/.ssh{,.old}; passwd -l USERNAME; pkill -u USERNAME

If the user still have other avenues to enter the system such as FTP or WEBDAV or other methods, you will need to take care of those separately.

because passwd -l only locks the password, doesnt lock the login... unless i change the shell to /sbin/nologin which is disabling alr haha, thanks!

 

[davidktw]

because passwd -l only locks the password, doesnt lock the login... unless i change the shell to /sbin/nologin which is disabling alr haha, thanks!

Well of course that will depends on what you really wanted. Sometimes people use /dev/null as oppose to /sbin/nologin too. When it comes to SSH, it stops really just there. What it matters is when the same login mechanism also reference the /etc/passwd file such as FTP servers, having the need of a valid shell before allow to login. So you are using the same reference across multiple services.

Without the password and without the SSH authentication authorised_keys or authorised_keys2, I don't see how the person can login via SSH