catalogue
The sshd service supports two authentication methods
Two implementation methods of protection mechanism
Basic principles of TCP Wrappers mechanism
preface
Our work is often completed on the basis of server cluster. Whether it is data exchange between servers or our remote access to our server for daily maintenance, it is inseparable from our remote access.
SSH
SSH (Secure Shell) is a secure channel protocol, which is mainly used to realize the functions of remote login and remote replication of character interface. SSH
The protocol encrypts the data transmission between the communication parties, including the user password entered when the user logs in. SSH is a security protocol based on application layer and transmission layer.
Main functions of ssh server
- ssh Remote link
- sftp service
Function: SSHD service uses SSH protocol, which can be used for remote control or transfer files between computers.
Compared with the previous Telnet method, it is much safer to transfer files, because Telnet uses plaintext transmission and SSH is encrypted transmission
Service Name: sshd
Server main program: / usr/ sbin/sshd
Server configuration file: letc/ ssh/ sshd_config
configuration file
There are two common opensh configuration files, / etc/ssh/ssh_config and / etc/sshd_config
ssh_config: it is a client configuration file to set client related applications, which can be implemented through this file
sshd_config: it is a server-side configuration file, which can be used to set applications related to the server-side
ssh Remote Login mode
ssh [remote host user name] [remote server host name or IP address] - P port (specify the corresponding port)
ssh -l [remote host user name] [remote server host name or IP address] - p port
-L: - L option, specify the login name.
-p: -p option, specify the login port (when the port of the server is not the default, you need to use - P to specify the port for login)
Service configuration
#Listening port modify the experimental setting of SHD listening port number.
SSH uses 22 ports by default, or multiple ports can be used, that is, the port setting is reused!
For example, if you want to open SSHD ports 22 and 222, you can add an additional line as Port 222.
Then restart ssHD. That's good. It is recommended that you modify port number to other ports to prevent others from brutally cracking
vim /etc/ssh/sshd_config 17 #Port 22 #The default listening port is 22 18 #AddressFamily any 19 #ListenAddress 0.0.0.0 #The listening address is any network segment 20 #ListenAddress :: 37 #LoginGraceTime 2m #The login verification time is two minutes 38 #PermitRootLogin yes #Allow root to log in 39 #StrictModes yes 40 #MaxAuthTries 6 #The maximum number of retries is 6 41 #MaxSessions 10 62 # To disable tunneled clear text passwords, change to no here! 63 #PasswordAuthentication yes 64 #PermitEmptyPasswords no #Prohibit users with blank passwords from logging in 65 PasswordAuthentication yes 115 #UseDNS no #Disable DNS reverse resolution to improve response speed White list and blacklist can be configured manually 140 AllowUsers ghr1 ghr2 ghr3@192.168.90.138 #We allow ghr3 to log in to the machine remotely, and ghr3 can log in only with the specified ip 141 DenyUsers ghr5 #No ghr5 login [root@192 ~]# ssh ghr3@192.168.90.137 #Successfully log in to the host using the IP of 138 ghr3@192.168.90.137's password: Last failed login: Mon Sep 6 23:26:34 CST 2021 from 192.168.90.139 on ssh:notty There was 1 failed login attempt since the last successful login. Last login: Mon Sep 6 23:26:24 2021 from 192.168.90.138 [ghr3@192 ~]$ [root@192 ~]# ssh ghr3@192.168.90.137 #Neither ghr3 nor ghr5 can log in using 139 ip ghr3@192.168.90.137's password: Permission denied, please try again. ghr3@192.168.90.137's password: [root@192 ~]# ssh ghr5@192.168.90.137 ghr5@192.168.90.137's password: Permission denied, please try again. ghr5@192.168.90.137's password:
scp remote replication
[root@192 home]# scp -r ghr5@192.168.90.138:/home/test/ /home/test #Download all files under / home/test from the other host to our host under / home/test The authenticity of host '192.168.90.138 (192.168.90.138)' can't be established. ECDSA key fingerprint is SHA256:3JNdskzW/U0r0Oc7HHFyWqErUrkk6c7MWG1mIDTR1Kg. ECDSA key fingerprint is MD5:b5:1c:73:bb:08:4f:4f:c6:98:98:17:c6:23:f8:27:98. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.90.138' (ECDSA) to the list of known hosts. ghr5@192.168.90.138's password: a.txt 100% 7 17.7KB/s 00:00 [root@192 home]# scp -r /home/test/* ghr5@192.168.90.138:/home/ghr5/ #To transfer the files from your own server to the server on the other side, it should be noted that the transfer must be carried out within the permission range of the account used ghr5@192.168.90.138's password: b.txt 100% 6 13.6KB/s 00:00 a.txt 100% 7 9.3KB/s 00:00
sftp Secure FTP
- Through the sftp command, you can upload and download files with the remote host through SSH secure connection. The login process and interactive environment similar to FTP are adopted to facilitate directory resource management
- Due to the use of encryption / decryption technology, the transmission efficiency is lower than ordinary FTP, but the security is higher
sftp root@192.168.126.15 root@192.168.126.15's password: Connected to 192.168.126.15. sftp> ls sftp> get file name #Download File ftp directory sftp> put file name #Upload file ftp directory sftp> exit #sign out [root@192 home]# sftp root@192.168.90.138 #Log in to the peer server root@192.168.90.138's password: Connected to 192.168.90.138. sftp> get /home/addnum.sh #Get test file Fetching /home/addnum.sh to addnum.sh /home/addnum.sh 100% 53 4.9KB/s 00:00 sftp> eixt #sign out [root@192 home]# ls #The file is downloaded to the current working environment addnum.sh ghr ghr1 ghr2 ghr3 ghr5 test [root@192 home]# sftp root@192.168.90.138 root@192.168.90.138's password: Connected to 192.168.90.138. sftp> put /home/?.txt #Upload files to the user's home directory Uploading /home/?.txt to /root/?.txt /home/?.txt 100% 6 9.4KB/s 00:00 sftp> ls /root #Upload succeeded /root/1111 /root/?.txt /root/anaconda-ks.cfg /root/initial-setup-ks.cfg /root/download /root/public /root/picture /root/file /root/desktop /root/Template /root/video /root/music sftp>
The sshd service supports two authentication methods
Password verification
- Verify the login name and password of the local system user in the server. Simple, but may be brutally cracked
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 file is placed in the specified location in the server. During remote login, the system will use public key and private key for encryption / decryption Association verification. It can enhance security and avoid interactive login
- When both password authentication and key pair authentication are enabled, the server will give priority to key pair authentication. The verification method can be set according to the actual situation
vim /etc/ssh/sshd_config PasswordAuthentication yes #Enable password authentication PubkeyAuthentication yes #Enable key pair authentication AuthorizedKeysFile .ssh/authorized_keys #Specifies the public key library file
43 PubkeyAuthentication yes #Enable key validation 44 45 # The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2 46 # but this is overridden so installations will only check .ssh/authorized_keys 47 AuthorizedKeysFile .ssh/authorized_keys #Specify public key file library 48 49 #AuthorizedPrincipalsFile none 50 51 #AuthorizedKeysCommand none 52 #AuthorizedKeysCommandUser nobody 53 54 # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts 55 #HostbasedAuthentication no 56 # Change to yes if you don't trust ~/.ssh/known_hosts for 57 # HostbasedAuthentication 58 #IgnoreUserKnownHosts no 59 # Don't read the user's ~/.rhosts and ~/.shosts files 60 #IgnoreRhosts yes 61 62 # To disable tunneled clear text passwords, change to no here! 63 #PasswordAuthentication yes 64 #PermitEmptyPasswords no 65 PasswordAuthentication yes #Enable password authentication
[root@192 ~]# su ghr1 #Switch users [ghr1@192 root]$ ssh-keygen -t ecdsa #Creating keys using scdas algorithm Generating public/private ecdsa key pair. Enter file in which to save the key (/home/ghr1/.ssh/id_ecdsa): #Specify key storage directory Created directory '/home/ghr1/.ssh'. Enter passphrase (empty for no passphrase): #Input password Enter same passphrase again: Your identification has been saved in /home/ghr1/.ssh/id_ecdsa. Your public key has been saved in /home/ghr1/.ssh/id_ecdsa.pub. The key fingerprint is: SHA256:nTjKWgdteVb56qIDXAe4nAPfJ58SlQzXp1AY1ezFCfg ghr1@192.168.90.140 The key's randomart image is: +---[ECDSA 256]---+ | ..ooB++...| | . . ..*...+.o| | + + o .++ . | | *.=+oo.E. | | ..oS*=. . | | .o+.+o . | | +... . | | o .. .. | | . .o .. | +----[SHA256]-----+ [ghr1@192 root]$ cd /home/ghr1 [ghr1@192 ~]$ cd .ssh [ghr1@192 .ssh]$ ls -a . .. id_ecdsa id_ecdsa.pub [ghr1@192 .ssh]$ scp ~/.ssh/id_ecdsa.pub root@192.168.90.137:/opt The authenticity of host '192.168.90.137 (192.168.90.137)' can't be established. ECDSA key fingerprint is SHA256:3JNdskzW/U0r0Oc7HHFyWqErUrkk6c7MWG1mIDTR1Kg. ECDSA key fingerprint is MD5:b5:1c:73:bb:08:4f:4f:c6:98:98:17:c6:23:f8:27:98. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.90.137' (ECDSA) to the list of known hosts. root@192.168.90.137's password: id_ecdsa.pub 100% 181 237.8KB/s 00:00 [ghr1@192 .ssh]$ ssh root@192.168.90.137 Enter passphrase for key '/home/ghr1/.ssh/id_ecdsa': Last failed login: Tue Sep 7 00:58:04 CST 2021 from 192.168.90.138 on ssh:notty There were 4 failed login attempts since the last successful login. Last login: Mon Sep 6 22:23:54 2021 from 192.168.90.1 [root@192 ~]#
TCP Wrappers access control
Two implementation methods of protection mechanism
- To protect other service programs directly using tcpd program, you need to run tcpd
- libwrap.so. * link library is called by other network service programs without running tcpd program; This method is more widely used and more efficient
rpm -q tcp_wrappers #Check to see if it is installed #Check the libwrap of the program and the link library of so. * ldd [parameter] [file] #Need to write absolute path
Access policy of TCP Wrappers
- The protection objects of TCP Wrappers mechanism are various network service programs, which perform access control for the client address accessing the service.
- The two corresponding policy files are / etc/hosts.allow and / etc/hosts.deny, which are used to set the allow and deny policies respectively
Format: [service program list]: [client address list]
Service program list
ALL: represents ALL services
Single service program: such as "vsftpd"
A list of multiple service programs, such as "vsftpd,sshd"
Client address list
ALL: represents any client address
LOCAL: represents the LOCAL address
Network segment address, such as 192.168.80. Or 192.168.80.0 / 255.255.255.0
Wildcard '?' is allowed And "*", the former represents any length character, the latter represents only one character, and multiple addresses are separated by commas
Basic principles of TCP Wrappers mechanism
First, check the / etc/hosts.allow file. If a matching policy is found, access is allowed;
Otherwise, continue to check the / etc/hosts.deny file. If a matching policy is found, access will be denied;
If no matching policy can be found by checking the above two files, access is allowed.
Allow all, reject individual
Just add the corresponding rejection policy in the / etc/hosts.deny file
Allow individual, reject all
In addition to adding the allow policy in / etc/hosts.allow, you also need to set the reject policy of "ALL:ALL" in the / etc/hosts.deny file
TCP Wrappers configuration
vim /etc/hosts.allow #Passable documents sshd:12.0.0.1,192.168.126.* #Allow servers in all 192.168.126. Network segments to use sshd services vim /etc/hosts.deny #Forbidden documents sshd:ALL #All except the white list are prohibited
summary
Our work cannot be carried out without ssh, which is a highly secure transmission and remote connection service. We can modify the configuration file to protect our server from hackers and our password from disclosure. This greatly improves the security of the server. It is also a service we must master. We can't always use the intranet to complete the setting. Often we need to connect to the server remotely through ssh