Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

What are the advanced SSH security skills under linux

2025-04-07 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >

Share

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

What this article shares to you is about the advanced SSH security skills under linux. The editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article.

The SSH server configuration file is / etc/ssh/sshd_conf. After each change you make to it, you need to restart the SSH service for the changes to take effect.

1. Modify SSH listening port

By default, SSH listens on connection port 22, and attackers can use port scanning software to see if the host is running SSH services, and it is wise 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 look for lines like this:

Port 22

Change the port number and restart the SSH service:

/ etc/init.d/ssh restart

2. Only SSH version 2 is allowed

There are two versions of the SSH protocol, and it is more secure to use only SSH version 2. SSH protocol version 1 has security issues, including man-in-the-middle attack (man-in-the-middle) and injection (insertion) attack. Edit the / etc/ssh/sshd_config file and look for lines like this:

Protocol 2,1

Modify to

Protocol 2

Only specific users are allowed to log in through SSH

You do not allow root users to log in through SSH, because this is a huge unnecessary security risk. If an attacker gets root permission to log in to your system, it will cause more damage than if he gets an ordinary user right. Configure the SSH server to not allow root users to log in through SSH. Look for the following line:

PermitRootLogin yes

Change yes to no, and then restart the service. Now, if you want to use privileged users, you can log in as other users and then switch to root.

It is a wise choice to create a virtual user without actual permissions. Logging in to SSH with this user will not cause any damage even if the user is cracked. When creating this user, make sure it belongs to the wheel group, so that you can switch to the privileged user.

If you want a list of users to log in through SSH, you can specify them in the sshd_config file. For example, I want users anze, dasa, and kimy to log in through SSH. At the end of the sshd_config file, I add the following line:

AllowUsers anze dasa kimy

4. Create a custom SSH banner

If you want anyone connected to your SSH service to see a special message, you can create a custom SSH banner, just create a text file (mine is / etc/ssh-banner.txt), and enter any text message you want, such as:

* This is a private SSH service. You are not supposed to be here.*

* Please leave immediately. *

After editing, save the file and look for the following line in sshd_config:

# Banner / etc/issue.net

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

5. Use DSA public key authentication

Instead of using a 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 DSA public key authentication can protect your system from dictionary attacks, because you do not need to log in to the DSA service with a login name and password. Instead, you need a pair of SSH keys, a public key and a private key to keep the private key on your local machine. Put the public key on the server. When you start a SSH login session, the server checks the keys, and if they match, you can go directly to shell, and if they don't match, your connection will be automatically disconnected.

In this example, the private computer is called 'workstation 1' and the server is called 'server 1'. On both machines I have the same home directory, if the server and client home directory is different will not work, to achieve, you need to create a pair of keys on your private computer, command: ~ $ssh-keygen-t dsa, it will require you to enter a password 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 at ~ / .ssh/id_dsa and your public key is at .ssh / id_dsa.pub.

Next, copy the contents of ~ / .ssh/id_dsa.pub to the ~ / .ssh/authorized_keys file of 'server 1', and the contents of ~ / .ssh/id_dsa.pub look like this:

~ $cat .ssh / id_dsa.pub ssh-dss AAAAB3NzaC1kc3MAAACBAM7K7vkK5C90RsvOhiHDUROvYbNgr7YEqtrdfFCUVwMWc JYDusNGAIC0oZkBWLnmDu+y6ZOjNPOTtPnpEX0kRoH79maX8NZbBD4aUV91lbG7z604ZTdr LZVSFhCI/Fm4yROHGe0FO7FV4lGCUIlqa55+QP9Vvco7qyBdIpDuNV0LAAAAFQC/9ILjqII7n M7aKxIBPDrQwKNyPQAAAIEAq+OJC8+OYIOeXcW8qcB6LDIBXJV0UT0rrUtFVo1BN39cAWz5pu Fe7eplmr6t7Ljl7JdkfEA5De0k3WDs 9/rD1tJ6UfqSRc2qPzbn0p0j89LPIjdMMSISQqaKO4m2fO2VJcgCWvsghIoD0AMRC7ngIe6bta NIhBbqri10RGL5gh5AAACAJj1/rV7iktOYuVyqV3BAz3JHoaf+H/dUDtX+wuTuJpl+tfDf61rb WOqrARuHFRF0Tu/Rx4oOZzadLQovafqrDnU/No0Zge+WVXdd4ol1YmUlRkqp8vc20ws5mLVP 34fST1amc0YNeBp28EQi0xPEFUD0IXzZtXtHVLziA1 * NuzY = anze@station1.example.com

If the file ~ / .ssh/authorized_keys already exists, append the above to the file. All that's left is to set the correct permissions for the file:

~ $chmod 60000 ~ / .ssh/authorized_keys

Now, configure the sshd_config file to use DSA key authentication to make sure you remove the comments before the following three lines:

RSAAuthentication yes

PubkeyAuthentication yes

AuthorizedKeysFile h/.ssh/authorized_keys

Restart the service, and if your configuration is not wrong, you can now SSH to your server and go directly to your home directory without any interaction (such as entering a user name and password).

If you only want to log in using DSA authentication, make sure you uncomment and modify the line PasswordAuthentication in sshd_config and change yes to no:

PasswordAuthentication no

Anyone who does not have a public key on the server tries to connect to your SSH service, it is rejected, and the following rejection message is displayed to it:

Permission denied (publickey).

6. Use TCP wrappers to allow only specified host connections

If you want to allow only certain hosts to connect to your SSH service on your network, but do not want to use or mess up your iptables configuration, then this method is very useful, you can use TCP wrappers. In this example to TCP the sshd, I will create a rule that allows the local subnet 192.168.1.0 Maple 24 and the remote 193.180.177.13 to connect to my SSH service.

By default, TCP wrappers first looks in / etc/hosts.deny to see if the host is allowed to access the service. Next, TCP wrappers looks up / etc/hosts.allow to see if there are any rules that allow the service specified by the host service. I will create a rule in / etc/hosts.deny as follows:

Sshd: ALL

This means that by default all hosts are denied access to the SSH service, as it should, otherwise all hosts can access the SSH service, because the TCP wrappers first looks in the hosts.deny, and if there is no rule here to block the SSH service, any host can connect.

Next, create a rule in / etc/hosts.allow that allows the specified host to use the SSH service:

Sshd: 192.168.1 193.180.177.13

Now, only hosts from 192.168.1.0 take 24 and 193.180.177.13 can access the SSH service, and the other hosts are disconnected before they reach the login prompt and receive an error, as follows:

Ssh_exchange_identification: Connection closed by remote host

7. Use iptables to allow specific host connections

As an alternative to TCP wrappers, you can use iptables to restrict SSH access (but you can use both). Here is a simple example of how to allow a specific host to connect to your SSH service:

~ # iptables-An INPUT-p tcp-m state-- state NEW-- source 193.180.177.13-- dport 22-j ACCEPT

And make sure that no other hosts can access the SSH service:

~ # iptables-An INPUT-p tcp-- dport 22-j DROP

Save your new rules, your task is done, and the rules will take effect immediately.

8. SSH time locking skills

You can use different iptables parameters to restrict the connection to the SSH service so that it can connect within a specific time frame and not at other times. You can use the / second, / minute, / hour, or / day switches in any of the following examples.

In the first example, if a user enters the wrong password and does not allow access to the SSH service for a minute, each user can only try to log in once in a minute:

~ # iptables-An INPUT-p tcp-m state-- syn-- state NEW-- dport 22-m limit--limit 1/minute-- limit-burst 1-j ACCEPT

# iptables-An 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 login attempts, iptables allows the host to try to log in once a minute:

# iptables-An 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-An INPUT-p tcp-s 193.180.177.13-m state-- syn-- state NEW-- dport 22-j DROP

None of these techniques are difficult to master, but they are a powerful way to protect your SSH service, and get a good night's sleep at a small price.

These are the advanced SSH security skills under linux, and the editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

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.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Servers

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report