Advanced SSH security skills

In this article, I will show you some simple tips to help you improve the security of your SSH service. The SSH server configuration file is/etc/ssh/sshd_conf. After each modification, you must restart the SSH service to make the change take effect.

1. Modify the SSH listening port

By default, SSH listens to connection port 22. Attackers can use port scanning software to check whether the host runs the SSH service. It is a wise choice to change the SSH port to a port greater than 1024, because most port scanning software (including nmap) does not scan high ports by default.

Open the/etc/ssh/sshd_config file and find the following line:
Port 22

Modify the port number and restart the SSH service:
/Etc/init. d/ssh restart

2. Only SSH protocol version 2 is allowed

There are two versions of the SSH protocol. Only version 2 of the SSH protocol is safer. Version 1 of the SSH protocol has security issues, including man-in-the-middle attacks) and insertion attacks. Edit the/etc/ssh/sshd_config file and find the following line:
Protocol 2, 1
Change
Protocol 2

3. Only specific users are allowed to log on via SSH

You do not allow the root user to log on via SSH, because this is a huge and unnecessary security risk. If an attacker obtains the root permission to log on to your system, it can cause greater damage to a normal user. configuring the SSH server does not allow the root user to log on via SSH. Find the following line:
PermitRootLogin yes

Change yes to no and restart the service. Now, if you want to use a privileged user, you can first log on to another user and then switch to the root user.

Creating a virtual user without actual permissions is a wise choice. Using this user to log on to SSH will not cause any damage even if the user is cracked. When this user is created, make sure it belongs to the wheel group, because then you can switch to a privileged user.

If you want to allow a column of users to log on via SSH, you can specify them in the sshd_config file. For example, I want users to log on via SSH to anze, dasa, and kimy, add the following line at the end of the sshd_config file:
AllowUsers anze dasa kimy

4. Create a custom SSH banner

 

If you want any user connected to your SSH service to see a special message, you can create a custom SSH banner, just create a text file (My is/etc/ssh-banner.txt) and then enter any text message you want, such:
* This is a private SSH service. You are not supposed to be here .*
* Please leave immediately .*

After editing, save the file and find the following line in sshd_config:
# Banner/etc/issue.net

Uncomment [remove #], and then modify the path to your custom SSH banner text file.

5. Use the DSA Public Key for authentication

Instead of using the user name and password to authenticate SSH, you can use the DSA Public Key for authentication. Note that you can use either the login name or the DSA Public Key for authentication, using the DSA Public Key Authentication can prevent dictionary attacks on your system, because you do not need to log on to the SSH service with the login name and password, but need a pair of DSA keys, a public key and a private key, save the private key on your local machine and put the public key on the server. When you initiate an SSH login session, the server checks the keys. If they match, you can directly access the shell. If they do not match, your connection will be automatically disconnected.

In this example, the private computer is 'workstation 1' and the server is 'server 1 '. On both machines, I have the same home directory. If the home directory on the server and client is different, it will not work. To achieve this, you need to create a pair of keys on your private computer. Command :~ $ Ssh-keygen-t dsa, which requires you to enter a secret for the private key, but you can leave it blank because this is not a recommended practice. The key pair has been created: your private key is in ~ /. Ssh/id_dsa. Your public key is in. ssh/id_dsa.pub.

Next, copy ~ /. Ssh/id_dsa.pub content to 'server 1 ~ /. Ssh/authorized_keys file ,~ The content of/. ssh/id_dsa.pub looks like the following:



 
~ $ Cat. ssh/id_dsa.pub
Ssh-dss secure
JYDusNGAIC0oZkBWLnmDu + y6ZOjNPOTtPnpEX0kRoH79maX8NZbBD4aUV91lbG7z604ZTdr
LZVSFhCI/Fm4yROHGe0FO7FV4lGCUIlqa55 + QP9Vvco7qyBdIpDuNV0LAAAAFQC/9ILjqII7n
M7aKxIBPDrQwKNyPQAAAIEAq + OJC8 + OYIOeXcW8qcB6LDIBXJV0UT0rrUtFVo1BN39cAWz5pu
Fe7eplmr6t7Ljl7JdkfEA5De0k3WDs
9/second
NIhBbqri10RGL5gh4AAACAJj1/rV7iktOYuVyqV3BAz3JHoaf + H/dUDtX + wuTuJpl + tfDf61rb
WOqrARuHFRF0Tu/Rx4oOZzadLQovafqrDnU/No0Zge + WVXdd4ol1YmUlRkqp8vc20ws5mLVP
34fST1amc0YNeBp28EQi0xPEFUD0IXzZtXtHVLziA1/NuzY = anze@station1.example.com


If the file ~ /. Ssh/authorized_keys already exists. Add the above content to the end of the file. The rest is to set the correct permissions for the file:

~ $ Chmod 600 ~ /. Ssh/authorized_keys

Now, configure the sshd_config file to use the DSA key for authentication. Make sure that you have removed the comments before the following three lines:
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile % h/. ssh/authorized_keys

Restart the service. If your configuration is correct, now you can SSH to your server without any interaction actions (such as entering the user name and password) you can directly access your home directory.
If you only want to log in with DSA authentication, make sure that you cancel the annotation and modify the PasswordAuthentication line in sshd_config, and change yes to no:
PasswordAuthentication no

Anyone who has no public key on the server tries to connect to your SSH service will be denied, and the following denial message will be displayed to it:
Permission denied (publickey ).

6. use TCP wrappers to allow only the specified host to connect
If you want to allow only a specific host to connect to your SSH service on your network, but you do not want to use or mess up your iptables configuration, this method is very useful, you can use TCP wrappers. In this example, sshd is wrapped in TCP. I will create a rule that allows the local subnet 192.168.1.0/24 and remote 193.180.177.13 to connect themselves to my SSH service.
By default, TCP wrappers starts at/etc/hosts. deny to check whether the host allows access to the service. Next, TCP wrappers to find/etc/hosts. allow check whether there are rules that allow the specified service of the host service. create a rule in deny as follows:
Sshd: ALL
This means that by default, all hosts are denied access to the SSH service. Otherwise, all hosts can access the SSH service because TCP wrappers is first deployed in the hosts. deny. If there are no rules to block the SSH service, any host can connect.
Next, create a rule in/etc/hosts. allow to allow the specified host to use the SSH service:
Sshd: 192.168.1 193.180.177.13
Currently, only hosts from 192.168.1.0/24 and 193.180.177.13 can access the SSH service. Other hosts are disconnected when they are not logged on to the prompt and receive an error message, as shown below:
Ssh_exchange_identification: Connection closed by remote host
7. Use iptables to allow specific host connections
As a substitute for TCP wrappers, you can use iptables to restrict SSH access (but you can use both). Here is a simple example, this article explains how to allow a specific host to connect to your SSH service:
~ # Iptables-a input-p tcp-m state -- state NEW -- source 193.180.177.13 -- dport 22-j ACCEPT
Make sure that no other hosts can access the SSH service:
~ # Iptables-a input-p tcp -- dport 22-j DROP
Save your new rule, and your task is completed. The rule takes effect immediately.
8. SSH time locking skills
You can use different iptables parameters to restrict connections to the SSH service so that they can be connected within a specific time range, and cannot be connected at other times. You can use the/second,/minute,/hour, or/day switch in any of the following examples.
In the first example, if a user enters an incorrect password and is locked for one minute, access to the SSH service is not allowed. In this way, each user can log on only once within one minute:
~ # Iptables-a input-p tcp-m state -- syn -- state NEW -- dport 22-m limit -- limit 1/minute -- limit-burst 1-j ACCEPT
~ # Iptables-a input-p tcp-m state -- syn -- state NEW -- dport 22-j DROP
In the second example, set iptables to allow only the host 193.180.177.13 to connect to the SSH service. After three failed logon attempts, iptables allows the host to log on every minute:
~ # Iptables-a input-p tcp-s 193.180.177.13-m state -- syn -- state NEW -- dport 22-m limit -- limit 1/minute -- limit-burst 1-j ACCEPT
~ # Iptables-a input-p tcp-s 193.180.177.13-m state -- syn -- state NEW -- dport 22-j DROP
9. Conclusion
These skills are not very difficult to master, but they are a powerful means to protect your SSH service, and a good sleep is worth a little.

Source: http://www.linux.com/articles/61061