Shulou(Shulou.com)06/03 Report--

Preface

When linux operation and maintenance is managed, it is generally managed remotely. When hundreds of server hosts need to be managed from a workstation, remote maintenance will be more dominant.

I. SSH remote management

SSH is a secure channel protocol, which is mainly used to realize remote management and remote replication of character interface. SSH protocol encrypts the data transmission between the two sides of the communication, including the user password entered when the user logs in.

Compared with the early applications such as TELNET (remote login), RSH (Remote Shell) and RCP (Remote File Copy), SSH protocol provides better security.

SSH protocol

Provides a secure shell environment for clients to work with remote management default port: TCP 22

OpenSSH service name: sshd server main program: / usr/sbin/sshd server profile: / etc/ssh/sshd_config client profile: ssh_config

Service listening options port number, protocol version, listening IP address disable reverse resolution # Port 22 / / port number # AddressFamily any # ListenAddress 0.0.0.0 / / ipv4 listening address # ListenAddress:: / / ipv6 listening address

User login control

Disable root users, empty password login time, retry times AllowUsers, DenyUsers (blacklist, only allow and deny only) # LoginGraceTime 2m / / session time # PermitRootLogin yes / / whether to base root login # StrictModes yes / / whether to verify access # MaxAuthTries 6 / / verify 6 times # MaxSessions 10 / / the maximum number of links for access # PubkeyAuthentication yes / / whether to verify the public key

Login authentication object

Local user account in the server

Login authentication method

Password authentication: check whether the user name and password match

Key pair verification: check whether the customer's private key and the server's public key match

Use the SSH client program

Ssh command-remote secure login

Scp command-remote secure replication

Sftp command-- secure FTP download

Get download

Put upload

Bye exit

Using SSH services

1. Enter the SSH master server configuration file in tast01, change the configuration file entry, and enable the SSH service.

[root@tast01 ~] # vim / etc/ssh/sshd_config / / enter edit server configuration file information Port 22 / / Open port # AddressFamily any#ListenAddress 0.0.0.0#ListenAddress: wq / / Save exit [root@tast01 ~] # systemctl restart sshd / / restart SSH service

2. Log in to tast01 using SSH service in tast02.

[root@tast02 ~] # ssh root@192.168.144.133 / / use the SSH service to log in to the tast01 server The authenticity of host '192.168.144.133 (192.168.144.133)' can't be established.ECDSA key fingerprint is SHA256:B8IsZOFG7FbtVkIK+dMILmo0iA4OEIeVGY0GnnCbXhk.ECDSA key fingerprint is MD5:c2:d8:09:17:de:6e:ec:07:06:1b:ac:b6:1e:bd:62:09.Are you sure you want to continue connecting (yes/no)? Yes / / asks whether to establish a session Warning: Permanently added '192.168.144.133' (ECDSA) to the list of known hosts.root@192.168.144.133's password: / / enter the password Last login: Mon Sep 9 13:59:09 2019 [root@tast01 ~] # / / successfully log in to tast01 [root@tast01 ~] # exit / / exit Connection to 192.168.144.133 closed. [root@tast02 ~] # / return to tast02 port

3. Go back to the tast01 server, change the SSH server configuration file, and prohibit root users from logging in. Then create a siti user

[root@tast01 ~] # vim / etc/ssh/sshd_config / / enter and edit the main configuration file # LoginGraceTime 2mPermitRootLogin no / / whether to enable disable root login, and change yes to no Forbid root users to log in to # StrictModes yes#MaxAuthTries 6#MaxSessions 10:wq / / Save and exit [root@tast01 ~] # systemctl restart sshd / / restart the service [root@tast01 ~] # useradd siti / / create siti ordinary users [root@tast01 ~] # passwd siti / / set the user password to change the password of the user siti. New password: invalid password: password less than 8 characters re-enter the new password: passwd: all authentication tokens have been successfully updated. [root@tast01 ~] # id siti / / View new user siti information uid=1001 (siti) gid=1001 (siti) group = 1001 (siti) [root@tast01 ~] # id sun / / View user sun information uid=1000 (sun) gid=1000 (sun) group = 1000 (sun), 10 (wheel)

4. Root users who log in to tast01 using tast02 to see whether the changed service is effective.

[root@tast02 ~] # ssh root@192.168.144.133 / / use the SSH service to log in to the tast01 server root user root@192.168.144.133's password: / / enter the password to login to Permission denied, please try again. / / refuse to login to rootroot@192.168.144.133's password: Permission denied, please try again.root@192.168.144.133's password: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password). / / try to enter the password three times and pop up Refuse to log in [root@tast02 ~] # ssh siti@192.168.144.133 / / use SSH service to log in to siti user siti@192.168.144.133's password: [siti@tast01 ~] $/ / successfully log in to tast01 server siti user [siti@tast01 ~] $su-root / / use su to switch root users under siti user ] password: / / enter password Last login: September 9 15:16:00 CST 2019 last failed login from 192.168.144.135pts/1: September 9 15:33:03 CST 2019 from 192.168.144.135ssh:notty there were 3 failed login attempts after the most successful login. [root@tast01 ~] # / / successfully logged in to the root user. [root@tast01 ~] # exit / / exit login [siti@tast01 ~] $exit / / exit login Connection to 192.168.144.133 closed. [root@tast02 ~] # / / back to tast02 users

5. Through the above operations, we prohibit remote login to root, but we can switch login through ordinary users. At this time, we can turn on pam authentication in the tast01 system to improve the security of the system.

[root@tast01 ~] # vim / etc/pam.d/su / / enter the edit pam configuration file #% PAM-1.0auth sufficient pam_rootok.so# Uncomment the following line to implicitly trust users in the "wheel" group.#auth sufficient pam_wheel.so trust use_uid# Uncomment the following line to require a user to be in the "wheel" group.auth required pam _ wheel.so use_uid / / enable pam authentication auth substack system-authauth include postloginaccount sufficient pam_succeed_if.so uid = 0 use_uid quietaccount include system-authpassword include system-authsession include system-authsession include postloginsession optional pam _ xauth.so~ : wq / / Save exit

6. Check whether you can still switch to root users through siti users.

[root@tast02 ~] # ssh siti@192.168.144.133 / / Log in siti user siti@192.168.144.133's password: / / enter password Last failed login: Mon Sep 9 16:09:32 CST 2019 from 192.168.144.135 on ssh:nottyThere was 1 failed login attempt since the last successful login.Last login: Mon Sep 9 15:47:20 2019 from 192.168.144.135 [ Siti@tast01 ~] $su-root / / Log in to siti user And switch root user password: / / enter password su: permission denied / / permission denied, unable to switch [siti@tast01 ~] $

7. Because the permission is set, the siti user is not in the wheel group, so we cannot use the siti user to switch the root user. Can we switch the sun user in the wheel group through the siti user, and then switch the root with the sun user to see if it is possible.

[siti@tast01 ~] $su-sun / / switch sun user password: / / enter password su: permission denied / / permission denied, unable to switch [siti@tast01 ~] $

8. Go back to tast01 and enable the SSH service to configure password verification times.

[root@tast01 ~] # vim / etc/ssh/sshd_config / / enter the server configuration file # LoginGraceTime 2mPermitRootLogin no#StrictModes yesMaxAuthTries 6 / / enable password verification # MaxSessions 10:wq / / Save exit

9. Enter tast02 to verify whether the password is enabled successfully.

[root@tast02 ~] # ssh sun@192.168.144.133 / / Log in to sun user sun@192.168.144.133's password: / / enter the wrong password Permission denied, please try again. / / 1 error, refused to log in to sun@192.168.144.133's password: / / enter the wrong password Permission denied, please try again. / / 2 typed errors, refused to log in to sun@192.168.144.133's password: / / enter the wrong password Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password). / / 3 input errors log out directly

10. Through the above experiments, it is found that the password is not popped up six times, but three times by default. At this time, we use commands to increase the number of default passwords to set the number of times.

[root@tast02 ~] # ssh-o NumberofPasswordPrompts=8 sun@192.168.144.133 / / use the command to increase the number of password entries sun@192.168.144.133's password: Permission denied, please try again.sun@192.168.144.133's password: Permission denied, please try again.sun@192.168.144.133's password: Permission denied, please try again.sun@192.168.144.133's password: Permission denied, please try again.sun@192.168.144.133's password: Permission denied Please try again.sun@192.168.144.133's password: Received disconnect from 192.168.144.133 port 22:2: Too many authentication failuresAuthentication failed. / / enter the password for 6 times and then pop up. Set the setting to take effect.

Blacklist and whitelist settings (AllowUsers, DenyUsers)

Add another Linux client (tast03IP address: 192.168.144.132) to VMware 15 for remote connection to the server.

1. Configure the ssh server profile in tast01, add AllowUsers entries, and add clients that only allow login.

[root@tast01 ~] # vim / etc/ssh/sshd_config / / go to edit ssh server configuration file # LoginGraceTime 2mPermitRootLogin no#StrictModes yesMaxAuthTries 6#MaxSessions 10AllowUsers sun@192.168.144.135 stii / / add an entry here Only allow IP address 192.168.144.135 client login sun user only allows client login stii user # PubkeyAuthentication yes:wq / / Save exit [root@tast01 ~] # useradd stii / / add stii user [root@tast01 ~] # passwd stii / / set stii User password changes the password of user stii. New password: invalid password: password less than 8 characters re-enter the new password: passwd: all authentication tokens have been successfully updated. [root@tast01 ~] # systemctl restart sshd / / restart the ssh service

2. Use ssh service to remotely log in to the tast01 server in tast02 and tast03 clients, respectively.

[root@tast02 ~] # ssh sun@192.168.144.133 / / Log in to the server in the tast02 client sun user sun@192.168.144.133's password: / / enter the password Last failed login: Mon Sep 9 17:24:32 CST 2019 from 192.168.144.135 on ssh:nottyThere were 6 failed login attempts since the last successful login.Last login: Mon Sep 9 17:21:47 2019 from 192.168.144.133 [sun@tast01 ~] $/ / successfully log in [sun@tast01 ~] $exit / / the user logs out of Connection to 192.168.144.133 closed. [root@tast02 ~] # ssh siti@192.168.144.133 / / use ssh to log in to the server siti user siti@192.168.144.133's password: / / enter the password Permission denied Please try again. / / refuse to log in [root@tast02 ~] # ssh stii@192.168.144.133 / / Log in stii user stii@192.168.144.133's password: / / enter password [stii@tast01 ~] $/ / successfully log in to [root@tast03 ~] # ssh sun@192.168.144.133 / / tast03 client Use the ssh service to login to the server sun user The authenticity of host '192.168.144.133 (192.168.144.133)' can't be established.ECDSA key fingerprint is SHA256:B8IsZOFG7FbtVkIK+dMILmo0iA4OEIeVGY0GnnCbXhk.ECDSA key fingerprint is MD5:c2:d8:09:17:de:6e:ec:07:06:1b:ac:b6:1e:bd:62:09.Are you sure you want to continue connecting (yes/no)? Yes / / asks whether to establish a session, enter yes to confirm the establishment of the session Warning: Permanently added '192.168.144.133' (ECDSA) to the list of known hosts.sun@192.168.144.133's password: / / enter the password Permission denied, please try again. / / refuse to log in [root@tast03 ~] # ssh siti@192.168.144.133 / / tast03 client uses ssh service to login server siti user siti@192.168.144.133's password: / / enter password Permission denied, please try again. / / refuse to log in [root@tast03 ~] # ssh stii@192.168.144.133 / / tast03 client logs in to server using ssh service stii user stii@192.168.144.133's password: / / enter password Last login: Mon Sep 9 21:55:49 2019 from 192.168.144.135 [stii@tast01 ~] $/ / successfully

3. Go back to the tast01 server and edit the ssh server configuration file

[root@tast01 ~] # vim / etc/ssh/sshd_config / / Edit ssh server configuration file # LoginGraceTime 2mPermitRootLogin no#StrictModes yesMaxAuthTries 6#MaxSessions 10DenyUsers sun@192.168.144.135 stii / / Delete only allowed entries, add reject entry # PubkeyAuthentication yes:wq / / Save exit [root@tast01 ~] # systemctl restart sshd / / restart ssh service

4. Use ssh service to remotely log in to the tast01 server in tast02 and tast03 clients, respectively.

[root@tast02 ~] # ssh sun@192.168.144.133 / / Log in to the server in the tast02 client sun user sun@192.168.144.133's password: / / enter the password Permission denied, please try again. / / refuse to log in [root@tast02 ~] # ssh stii@192.168.144.133 / / Log in to the server in the tast02 client stii user stii@192.168.144.133's password: / / enter the password Permission denied, please try again. / / refuse to log in [root@tast02 ~] # ssh siti@192.168.144.133 / / Log in to the server in the tast02 client siti user siti@192.168.144.133's password: / / enter the password Last failed login: Mon Sep 9 22:02:00 CST 2019 from 192.168.144.132 on ssh:nottyThere were 2 failed login attempts since the last successful login.Last login: Mon Sep 9 21:53:53 2019 From 192.168.144.135 [siti@tast01 ~] $/ / successfully log in to [root@tast03 ~] # ssh stii@192.168.144.133 / / tast03 client login server using ssh service stii user stii@192.168.144.133's password: / / enter password Permission denied Please try again. / / refuse to log in [root@tast03 ~] # ssh sun@192.168.144.133 / / tast03 client logs in to server using ssh service sun user sun@192.168.144.133's password: / / enter password Last failed login: Mon Sep 9 22:30:55 CST 2019 from 192.168.144.135 on ssh:nottyThere was 1 failed login attempt since the last successful login.Last login: Mon Sep 9 22:24:51 2019 from 192.168.144.133 [sun@tast01 ~] $/ / successfully log in to [root@tast03 ~] # ssh siti@192.168.144.133 / / tast03 client login server using ssh service siti user siti@192.168.144.133's password: / / enter password Last login: Mon Sep 9 22:32:16 2019 from 192.168.144.135 [siti@tast01 ~] $/ / successfully logged in

Log in using key pair authentication

1. First, enter and edit the ssh configuration file in the tast01 server and open the key verification entry.

[root@tast01 ~] # vim / etc/ssh/sshd_config / / Edit ssh configuration file # LoginGraceTime 2mPermitRootLogin no#StrictModes yesMaxAuthTries 6#MaxSessions 10DenyUsers sun@192.168.144.135 stiiPubkeyAuthentication yes / / Open key pair authentication function # The default is to check both .ssh / authorized_keys and .ssh / authorized_keys2# but this is overridden so installations will only check .ssh / authorized_keysAuthorizedKeysFile .ssh / authorized_keys / / Key storage location: wq / / Save exit

2. Enter the client tast02 client and configure the key

[root@tast02 ~] # useradd siaa / / create a user in the tast02 client [root@tast02 ~] # passwd siaa / / set the user directory to change the password of the user siaa. New password: invalid password: password less than 8 characters re-enter the new password: passwd: all authentication tokens have been successfully updated. [root@tast02 ~] # su-siaa/ / switch to user siaa [siaa@tast02 ~] $ssh-keygen-t ecdsa / / make ecdsa type key Generating public/private ecdsa key pair.Enter file in which to save the key (/ home/siaa/.ssh/id_ecdsa): / / key storage location, keep unchanged Directly enter Created directory'/ home/siaa/.ssh'.Enter passphrase (empty for no passphrase): / / enter the password to be set Enter same passphrase again: / / enter the password Your identification has been saved in / home/siaa/.ssh/id_ecdsa.Your public key has been saved in / home/siaa/.ssh/id_ecdsa.pub.The key fingerprint is:SHA256:5mTvLU19q7uUUXECnEmNldB3S4gUiNZdvm1zupFUf0Y siaa@tast02The again Key's randomart image is:+--- [ECDSA 256]-+ | o + = Backgroundo. | | o oroom.roomo = | |. .. Oe | | +. | / / generate ecdsa key | S +. + = | =. .. = + = | |. .o ls.. | |. O+ | |. + = | +-- [SHA256]-+ [siaa@tast02 ~] $ls-a / / View the hidden files in the user's home directory. .. .bash _ logout .bash _ profile .bashrc .cache .config .mozilla .ssh [siaa@tast02 ~] $cd .ssh / / enter the generated .ssh directory [siaa@tast02 .ssh] $ls / / view the directory contents id_ecdsa id_ecdsa.pub / / generated private key and public key file [siaa@tast02 .ssh] $ssh-copy-id-I id_ecdsa. Pub siti@192.168.144.133 / / specifies that the generated public key file is pushed to the server siti user / bin/ssh-copy-id: INFO: Source of key (s) to be installed: "id_ecdsa.pub" The authenticity of host '192.168.144.133 (192.168.144.133)' can't be established.ECDSA key fingerprint is SHA256:B8IsZOFG7FbtVkIK+dMILmo0iA4OEIeVGY0GnnCbXhk.ECDSA key fingerprint is MD5:c2:d8:09:17:de:6e:ec:07:06: 1b:ac:b6:1e:bd:62:09.Are you sure you want to continue connecting (yes/no)? Yes / / query is a push Enter yes/bin/ssh-copy-id: INFO: attempting to log in with the new key (s), to filter out any that are already installed/bin/ssh-copy-id: INFO: 1 key (s) remain to be installed-- if you are prompted now it is to install the new keyssiti@192.168.144.133's password: / / enter the server siti user password Number of key (s) added: 1 / / successfully add the file Now try logging into the machine With: "ssh 'siti@192.168.144.133'" and check to make sure that only the key (s) you wanted were added. [siaa@tast02 .ssh] $ls / / View directory information id_ecdsa id_ecdsa.pub known_hosts / / create file Known_ hosts[ Siaa @ tast02 .ssh] $vim known_hosts / / View file information 192.168.144.133 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBC6sBj5BEqQkEIXTdcRDCzDlQRfhaoaY7OvyWzxcNxt+n6ZjbA1PSYK2SeTW3MAhUZOry7T6gNDFL7YyfMfXOGo= / / successfully push the key generated by ecdsa to the server

3. Go back to the tast01 server to see if there are any pushed files in the siti home directory

[root@tast01 ~] # cd / home/siti / / enter the siti home directory [root@tast01 siti] # ls-a / / to view hidden files. .bash _ history .bash _ profile .cache .mozilla.. .bash _ logout .bashrc .config .ssh [root@tast01 siti] # cd .ssh / / enter the added .ssh directory [root@tast01 .ssh] # ls / / View information authorized_ Keys [root @ tast01 .ssh] # cat authorized_keys / / View the ecdsa encrypted file of the message content ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBD6B4elJHibp7lYDfogSfd7krTUPyKzvLHZNk75GTm1oibrA0aMirgtwxxfUEOi+9+ZGU2V0C3+zH6vQpjvvPoo= siaa@tast02 / / siaa@tast02

4. Use the siaa user in the tast02 client to authenticate the siti user in the tast01 login server

[siaa@tast02 .ssh] $whoami / / use the command to view the current login user siaa/ / determine that the current login user is siaa [siaa@tast02 .ssh] $ssh siti@192.168.144.133 / / use the ssh service to log in to the server siti user Enter passphrase for key'/ home/siaa/.ssh/id_ecdsa': / / enter the set ecdsa password Last login : Mon Sep 9 22:37:19 2019 from 192.168.144.132 [siti@tast01 ~] $/ / successfully log in to the server siti user

5. Set the client to trust the user to log on to the server without authentication

[siti@tast01 ~] $exit / / exits the current user logs out of Connection to 192.168.144.133 closed. [siaa@tast02 .ssh] $ssh-agent bash / / returns the siaa user to tast02 Use the command agent bash environment [siaa@tast02 .ssh] $ssh-add / / add the authentication password Enter passphrase for / home/siaa/.ssh/id_ecdsa: / / enter the authentication password Identity added: / home/siaa/.ssh/id_ecdsa (/ home/siaa/.ssh/id_ecdsa) / / successfully add the password [siaa@tast02 .s sh] $ssh siti@192.168.144.133 / / Log in to the server siti user Last login: Mon Sep 9 23:31:28 2019 from 192.168.144.135 [siti@tast01 ~] $/ / successfully logged in Free of password authentication

SSH client program

1. Go to the tast01 server, edit the SSH configuration file, and log in to root, because some paths in the Linux system do not have root permissions and cannot achieve replication.

[root@tast01 ~] # vim / etc/ssh/sshd_config...// omitted part of the content. # Authentication:#LoginGraceTime 2mPermitRootLogin yes / / enable login root user rights # StrictModes yesMaxAuthTries 6#MaxSessions 10PubkeyAuthentication yes# The default is to check both .ssh / authorized_keys and .ssh / authorized_keys2:wq / / Save and exit [root@tast01 ~] # systemctl restart sshd / / restart the SSH service

2. Verify whether the login permission of root user is enabled successfully in tast02.

[root@tast02 ~] # ssh root@192.168.144.133 / / Log in to the server using the ssh service root user root@192.168.144.133's password: / / enter the user password Last login: Wed Sep 11 22:56:28 2019 from 192.168.144.135 [root@tast01 ~] # / / successfully logged in

3. Log out of the server in tast02, log in to the root user, create a file in the opt directory, and use the scp command to push it to the tast01 user.

[root@tast01 ~] # exit / / exit Connection to 192.168.144.133 closed. [root@tast02 ~] # cd / opt/ enter the opt directory [root@tast02 opt] # ls / / check out [root @ tast02 opt] # echo "this is ssh-client" > ssh_client.txt / / create a .txt file [root@tast02 opt] # mkdir-p tast / si11 / / Recursively create a tast directory and create a si11 directory under the tast directory [root@tast02 opt] # ls / / View rh ssh_client.txt tast / / successfully create files and directories [root@tast02 opt] # scp ssh_client .txt root@192.168.144.133:/home/ push the created .txt file to the server root user home directory root@192.168.144.133's password: / / enter the password ssh_client.txt 100% 19 6.0KB/s 00:00 / / successfully pushed

4. Go back to the tast01 server and check whether there are any files pushed to the past in the home directory.

[root@tast01 ~] # ls / home/ View the file under the home directory ssh_client.txt sun / / successfully add the file [root@tast01 ~] # cat / home/ssh_client.txt / / View the file content this is ssh-client / / display the file content

5. Push the newly created folder to the tast01 server in tast02, and check the tast01 server to see if the push is successful.

[root@tast02 opt] # scp-r tast/ root@192.168.144.133:/home/ push folder root@192.168.144.133's password: / / enter password [root@tast02 opt] # / / push successfully [root@tast01 ~] # ls / home/ / / View home directory ssh_client.txt sun tast/ / display pushed folder [root@tast01 ~] # ls / home/tast/ View folder contents si11 / / display the created si11 directory

Remote upload and download using sftp command

1. Delete the created files and folders in tast02

[root@tast02 opt] # ls / / View information rh ssh_client.txt tast/ / display content [root@tast02 opt] # rm-rf ssh_client.txt / / Delete txt file [root@tast02 opt] # rm-rf tast/ Delete folder [root@tast02 opt] # ls / / View rh / / deleted successfully

2. Download files from the tast01 server using the sftp command

[root@tast02 opt] # sftp root@192.168.144.133 / / use the sftp command to log in to the tast01 server root user root@192.168.144.133's password: / / enter the password Connected to 192.168.144.133. Sftp > ls / / successfully log in and view directory information anaconda-ks.cfg initial-setup-ks.cfg download public picture document desktop template / / at this time in root Sftp > cd / home/ enter the home directory under the user's home directory sftp > ls / / View ssh_client.txt sun tast / / display content sftp > get ssh_client.txt / / use the get command to download the txt file Fetching / home/ssh_client.txt to ssh_client.txt / home/ssh_client.txt 100% 19 19.3KB/s 00:00 sftp > bye / / exit [root@tast02 opt] # ls / / check whether there is content rh ssh in the directory _ client.txt / / downloaded successfully

3. Change the name of the downloaded file, upload the file to the tast01 server home directory using the sftp command, and go back to the tast01 server to view the information

[root@tast02 opt] # mv ssh_client.txt ssh_server.txt / / change the file name [root@tast02 opt] # ls / / View rh ssh_server.txt / / changed [root@tast02 opt] # sftp root@192.168.144.133 / / use the sftp command to log in to tast01root User root@192.168.144.133's password: / / enter password Connected to 192.168.144.133.sftp > cd / home/ enter home directory sftp > ls / / View content ssh_client.txt sun tast Sftp > put ssh_server.txt / / upload files to the tast01 server home directory Uploading ssh_server.txt to / home/ssh_server.txtssh_server.txt 100% 19 15.6KB/s 00:00 sftp > bye / / exit [root@tast02 opt] # [root@tast01 ~] # ls / home/ View the contents of the home directory ssh_client.txt ssh_server.txt sun tast / / upload the file successfully

TCP wrappers access control

Overview of TCP wrappers

Protection principle

TCP wrappers "packages" other TCP service programs, adding a secure detection process, and external connection requests must pass this layer of security inspection before they can access the real service program. TCP wrappers can also record all attempts to access protected services, providing administrators with a wealth of security analysis data. The access of TCP wrappers is an application service based on TCP protocol.

The implementation of protection mechanism

Method 1: wrap other service programs through the tcpd main program

Mode 2: other service programs call the libwrap.os.* connection library

Configuration file for access control policy

/ etc/hosts.allow

/ etc/hosts.deny

TCP Wrappers policy application

Set access control policy

Policy format: service list: client address list service list

Multiple services are separated by commas, and ALL represents a list of client addresses for all services

Multiple addresses are separated by commas, and ALL represents all addresses

Allow wildcards? And *

Address of network segment, such as 192.168.4.0 or 192.168.4.0Universe 255.255.255.0

Area address, such as: .benet.com

The order in which the policy is applied is to check the hosts.allow first. If a match is found, access is allowed. Otherwise, hosts.deny is checked. If there is no matching policy in the two files, access is allowed by default.

Example of policy application

Access to sshd services is only allowed from the following address

Host 61.63.65.67

Network segment 192.168.2.0Universe 24

Prohibit all other addresses from accessing protected services

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.