Allow or disallow ssh or telnet operations by configuring hosts.allow and hosts.deny files
1. Log in to the host. If it is a normal account, switch to the root account first.
su root
2. Edit /etc/hosts.allow file
vi /etc/hosts.allow
allow content |
Writing format (change to the desired IP or IP segment) |
ssh allows a single ip |
sshd:192.168.220.1 |
ssh allow ip segment |
sshd:192.168.220. |
telnet allows a single ip |
in.telnetd:192.168.220.1 |
telnet allow ip segment |
in.telnetd:192.168.221. |
Taking ssh to allow 192.168.220.1 and telnet to allow 192.168.220 network segment as an example, the specific content in /etc/hosts.allow is as follows:
3. Edit the /etc/hosts.deny file
vi /etc/hosts.deny
Add to the file:
sshd:ALL in.telnetd:ALL
Specifically, add the following content to /etc/hosts.deny:
4. After saving the file and exiting the editor, restart the ssh service and telnet service [ optional ]
service sshd restart service xinetd restart
illustrate:
1. When an IP request is connected, the Linux inspection strategy is to first see whether it is allowed in /etc/hosts.allow, and if it is allowed to pass directly; if not, then see if it is forbidden in /etc/hosts.deny, if it is forbidden, then Access is prohibited.
2. The experiment found that the configuration of /etc/hosts.allow and /etc/hosts.deny will take effect immediately without restarting, but it will not be affected whether the current session is restarted or not; that is to say, for the previously connected , even if the IP has been configured to prohibit login sessions, it will not be forced to disconnect. But I don't know if all linux are the same, so the fourth step is marked as optional.
3. I found some tutorials written on the Internet are not sshd but in. sshd is not in.telnetd but telnetd. Personally, I think it should be started independently without adding in. If it is hosted on xinetd , you need to add in.