Implementation of remote access control in CentOS 7.4

Time:2021-1-21

1、 SSH Remote Management

SSH is a secure channel protocol, which is mainly used to realize remote login, remote replication and other functions of character interface. SSH protocol encrypts the data transmission of both sides of communication, including the user password entered when the user logs in. Compared with early applications such as telent, RSH, RCP, etc., SSH protocol provides better security.

1. Configure openssh server

In CentOS 7.4 system, openssh server is provided by openssh, openssh server and other software packages (installed by default), and sshd has been added as a standard system service. Execute the command “systemctl start sshd” to start the sshd service. Most users, including root, can log in to the system remotely. The configuration file of sshd service is located in / etc / SSH / sshd by default_ Config directory, the correct adjustment of the relevant configuration items, can further improve the security of sshd remote login.

1) Service listening options

The default port number used by sshd service is 22. If necessary, it is suggested to modify this port number and specify the specific IP address of monitoring service to improve the concealment in the network. The security of V2 version is better than V1 version. Disabling DNS reverse resolution can improve the response speed of the server.

[ [email protected]centos01  ~]# vim /etc/ssh/sshd_ Config <! -- edit sshd main configuration file -- >
17 port 22 <! -- the listening port is 22 -- >
19 listenaddress 192.168.100.10 <! -- the listening address is 192.168.100.10-- >
21 protocol 2 <! -- Using SSH V2 protocol -- >
118 usedns no <! -- Disable DNS reverse resolution -- >
... <! -- omit part here -- >
[ [email protected]  ~]#Systemctl restart sshd <! -- restart sshd Service -- >

2) User login control

The sshd service allows the root user to log in by default, but it is very insecure when used in the Internet. As for the control of user login in sshd service, the root user or the user whose password is empty should be forbidden to login. In addition, you can limit the time of login verification (2 minutes by default) and the maximum number of retries. If you fail to login after exceeding the limit, you will disconnect.

[ [email protected]  ~]# vim /etc/ssh/sshd_ Config <! -- edit sshd main configuration file -- >
 37 logingracetime 2m <! -- login verification time is 2 minutes -- >
 38 permitrootlogin yes <! -- forbid root login -- >
 40 maxauthtries 6 <! -- the maximum number of retries is 6 -- >
 67 permittemptypasswords no <! -- users with empty password are not allowed to log in -- >
 ... <! -- omit part here -- >
[ [email protected]  ~]#Systemctl restart sshd <! -- restart sshd Service -- >

2. Login authentication method

For the remote management of the server, in addition to the security control of the user account, the login authentication method is also very important. The sshd service supports two authentication methods: password authentication and key pair authentication. Only one of them can be set or both can be enabled.

Password verification: verify the login name and password of the local system user in the server. This is the most convenient way to use, but from the perspective of the client, the server being connected may be counterfeited; from the perspective of the server, when encountering the third party of password exhaustion, the defense ability is relatively weak.

Key pair verification: matching key information is required to pass the verification. Usually, a pair of key files (public key and private key) are created in the client, and then the public key files are put to the specified location in the server. When remote login, the system will use public key and private key for encryption / decryption Association verification, which greatly enhances the security of remote management. This method is not easy to be counterfeited, and can be free of interactive login, so it is widely used in shell.

When both password verification and key pair verification are enabled, the server will give priority to key pair verification. For servers with high security requirements, it is recommended to disable the password authentication mode and only enable the key pair authentication mode; if there are no special requirements, both modes can be enabled.

[ [email protected]  ~]# vim /etc/ssh/sshd_ Config <! -- edit sshd main configuration file -- >
 43 pubkeyauthentication yes <! -- enable key pair authentication -- >
 47 AuthorizedKeysFile   .ssh/authorized_ Keys <! -- specifies the public key library file -- >
 66 passwordauthentication yes <! -- enable password authentication -- >
... <! -- omit part here -- >
[ [email protected]  ~]#Systemctl restart sshd <! -- restart sshd Service -- >

The public key file is used to save the public key text uploaded by multiple clients, so as to match with the local private key file of the client.

2、 Using SSH client program

In CentOS 7.4 system, openssh client is provided by openssh clients (installed by default), including SSH Remote Login command, SCP, SFTP remote copy and file transfer command.

1. Command program SSH Remote Login

Through SSH command, we can log in to sshd service remotely, and provide a secure shell environment for users to manage and maintain the server. The login user and target host address should be specified as parameters. Examples are as follows:

[[email protected] ~]# ssh [email protected]
[email protected]'s password: 
Last login: Mon Nov 11 19:02:50 2019 from 192.168.100.254
[[email protected] ~]# 
[[email protected] ~]# 
[[email protected] ~]# ssh [email protected]
The authenticity of host '192.168.100.10 (192.168.100.10)' can't be established.
ECDSA key fingerprint is SHA256:PUueT9fU9QbsyNB5NC5hbSXzaWxxQavBxXmfoknXl4I.
ECDSA key fingerprint is MD5:6d:f7:95:0e:51:1a:d8:9e:7b:b6:3f:58:51:51:4b:3b.
Are you sure you want to continue connecting (yes / no)? Yes <! -- accept key -- >
Warning: Permanently added '192.168.100.10' (ECDSA) to the list of known hosts.
[email protected] 's password: <! -- enter password -- >
Last login: Mon Nov 11 19:03:08 2019 from 192.168.100.20
[ [email protected]  ~]#Who <! -- confirm current user -- >
root   pts/1    2019-11-11 19:03 (192.168.100.20)
root   pts/2    2019-11-11 19:04 (192.168.100.10)

If the sshd server uses a non default port (such as 2222), you must specify the port number through the “- P” option when logging in. Examples are as follows:

[ [email protected]  ~]# vim /etc/ssh/sshd_ Config <! -- modify SSH master configuration file -- >
Port 2222 <! -- change the listening port number to 2222 -- >
[ [email protected]  ~]#Systemctl restart sshd <! -- restart sshd Service -- >
[ [email protected]  ~]# ssh -p 2222  [email protected]    <! -- client login SSH -- >
[email protected] 's password: <! -- enter password -- >
Last login: Mon Nov 11 19:20:28 2019 from 192.168.100.10
[ [email protected]  ~]#<! -- login successfully -- >

2. SCP remote replication

Through the SCP command, you can use SSH security connection to copy files with the remote host. When using the SCP command, you must specify not only the copy source and target, but also the target host address and login user. After execution, you can enter the verification password according to the prompt. Examples are as follows:

[[email protected] ~]# scp
[email protected]:/etc/ssh/sshd_config ./ 
     <! -- copy the remote host data to the local data and save it in the current location -- >
[email protected] 's password: <! -- enter password -- >
sshd_config          100% 3910   3.6MB/s  00:00  
[[email protected] ~]# scp -r ./sshd_config
[email protected]:/opt   
     <! -- upload local data to opt in remote host directory -- >
[email protected] 's password: <! -- enter password -- >
sshd_config          100% 3910   1.2MB/s  00:00

3. SFTP install FTP

Through the SFTP command, we can use SSH secure connection to upload and download files with the remote host. We use the login process and interactive environment similar to FTP, which is convenient for directory resource management. Examples are as follows:

[ [email protected]  ~]#CD / opt / <! -- enter the opt directory -- >
[ [email protected]  opt]# sftp  [email protected]   <! -- login SFTP -- >
[email protected] 's password: <! -- enter password -- >
Connected to 192.168.100.20.
SFTP > PWD <! -- view the location where the client logs in to SFTP. By default, the location is in the host directory -- >
Remote working directory: /root
sftp> put sshd_ Config <! -- upload data to remote host -- >
Uploading sshd_config to /root/sshd_config
sshd_config          100% 3910   6.4MB/s  00:00  
sftp> get sshd_ Config <! -- download data to local -- >
Fetching /root/sshd_config to sshd_config
/root/sshd_config       100% 3910   3.6MB/s  00:00  
SFTP > Exit <! -- log out -- >

3、 Constructing SSH system of key pair verification

Key pair authentication can provide better security for remote login. The basic process of building key pair in Linux server and client to verify SSH system. As shown in the figure below, the whole process includes four steps. First, create a key pair in the SSH client as Zhangsan user, and upload the created public key file to the ssh server. Then, import the public key information into the public key database of the target user Lisi on the server. Finally, log in and verify as the server user Lisi.

1. Creating a key pair on the client side

In the client, the SSH keygen tool is used to create the key pair file for the current user. The encryption algorithms available are ECDSA or DSA (the “- t” option of the SSH keygen command is used to specify the algorithm type). Examples are as follows:

[ [email protected]  ~]#SSH keygen - t DSA <! -- create key pair -- >
Generating public/private dsa key pair.
Enter file in which to save the key (/root/.ssh/id_ DSA): <! -- specify private key location -- >
Created directory '/root/.ssh'.
Enter password (empty for no password): <! -- set private key phrase -- >
Enter same password again: <! -- confirm the set phrase -- >
Your identification has been saved in /root/.ssh/id_dsa.
Your public key has been saved in /root/.ssh/id_dsa.pub.
The key fingerprint is:
SHA256:zv0EdqIuOfwSovN2Dkij08y9wZ0f1+IyhY7LFNKKzkk [email protected]
The key's randomart image is:
+---[DSA 1024]----+
|         |
|         |
|         |
|   .      |
| o . o S.+ .  |
| * *.+.=.+.=   |
|o E.*o+==.+ o  |
| =o..*Oo++ +   |
| ++oo+*+o. .  |
+----[SHA256]-----+
[ [email protected]  ~]# ls -lh ~/.ssh/id_ DSA * <! -- confirm the generated key file -- >
-RW ------ 1 root root 668 November 12 16:11 / root /. SSH / ID_ dsa
-Rw-r -- R -- 1 root 603 November 12 16:11 / root /. SSH / ID_ dsa.pub

In the newly generated key pair file, ID_ DAS is a private key file with the permission of 600 by default. The private key file must be kept properly and cannot be disclosed to others_ dsa.pub Is the public key file, used to provide to the ssh server.

2. Upload the public key file to the server

Upload the public key file generated in the previous step to the server and deploy it to the public key database of the server-side user. When uploading the public key file, you can choose SCP, FTP, HTTP or even e-mail.

[email protected] ~]# ssh-copy-id -i ./.ssh/id_dsa.pub 
[email protected]  <! -- upload the public key file to the server and import the public key text -- >
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "./.ssh/id_dsa.pub"
The authenticity of host '192.168.100.10 (192.168.100.10)' can't be established.
ECDSA key fingerprint is SHA256:PUueT9fU9QbsyNB5NC5hbSXzaWxxQavBxXmfoknXl4I.
ECDSA key fingerprint is MD5:6d:f7:95:0e:51:1a:d8:9e:7b:b6:3f:58:51:51:4b:3b.
Are you sure you want to continue connecting (yes / no)? Yes <! -- enter yes --
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
[email protected] 's password: <! -- enter password -- >

Number of key(s) added: 1

Now try logging into the machine, with:  "ssh '[email protected]'"
and check to make sure that only the key(s) you wanted were added.

3. Using key pair authentication in client

When the private key file (client) and public key file (server) are deployed in place, the test can be carried out in the client. First confirm that the current user in the client is root, and then log in remotely as the root of the server through SSH command. If the key pair verification mode is configured successfully, the client will require the input of the private key phrase to call the private key file for matching (if the private key phrase is not set, log in to the target server directly).

[ [email protected]  ~]# ssh  [email protected]    <! -- log in to ssh server -- >
Last login: Tue Nov 12 16:03:56 2019 from 192.168.100.254
[ [email protected]  ~]#Who <! -- log in to the server successfully, and check which users are there -- >
root   pts/0    2019-11-12 17:35 (192.168.100.20)
root   pts/2    2019-11-12 16:03 (192.168.100.254)

The above is the whole content of this article, I hope to help you learn, and I hope you can support developer more.

Recommended Today

Swift advanced (XV) extension

The extension in swift is somewhat similar to the category in OC Extension can beenumeration、structural morphology、class、agreementAdd new features□ you can add methods, calculation attributes, subscripts, (convenient) initializers, nested types, protocols, etc What extensions can’t do:□ original functions cannot be overwritten□ you cannot add storage attributes or add attribute observers to existing attributes□ cannot add parent […]