Four tips for secure SSH access

More and more webmasters begin to use independent hosts (DedicatedHost) and VPS. In order to save costs or improve performance, many independent machines and VPS are all unmanaged bare-metal machines, and everything needs to be DIY. At this time, the implementation of security policies is still important. The following article uses CentOS as an example,

More and more webmasters begin to use independent hosts and VPS. In order to save costs or improve performance, many independent machines and VPS are all unmanaged bare-metal machines, and everything needs to be DIY. At this time, the implementation of security policies is still important. In the following article, I will take CentOS as an example to briefly summarize how to configure secure SSH access.

　　Linux SSH security policy 1: disable irrelevant ports

Most hosts attacked on the network are targeted by hackers who use scanning tools for a wide range of scans. Therefore, in order to avoid being scanned, all ports, such as Web, FTP, and SSH, should be disabled. It is worth mentioning that I strongly recommend that you disable icmp ports and set rules to discard icmp packets. In this way, if someone else cannot Ping your server, the threat will be reduced by half. To discard an icmp packet, add the following to iptables:

-A input-p icmp-j DROP

　Linux SSH security policy 2: Change the SSH Port

The default SSH port is 22. We strongly recommend that you change it to 10000 or above. In this way, the chances of other users scanning ports are also greatly reduced. Modification method:

# Edit/etc/ssh/ssh_config

Vi/etc/ssh/ssh_config

# Add a new Port value under Host. Take 18439 as an example (the same below ):

Port 22

Port 18439

# Edit/etc/ssh/sshd_config

Vi/etc/ssh/sshd_config

# Add a new Port value

Port 22

Port 18439

# Restart the SSH service after saving:

Service sshd restart

Here, I set two ports to prevent SSH from being unable to be accessed again due to modification errors. Change the connection Port of your SSH client (for example, Putty) and test the connection. if the new Port can be connected successfully, edit the above two files and delete the configuration of Port 22. If the connection fails, use Port 22 to connect and then reconfigure it.

After the port is successfully set, note that port 22 should be deleted from iptables, Port 18439 of the new configuration should be added, and iptables should be restarted.

If the SSH logon password is weak, you should set a complicated password. On the Google Blog, I wrote an article emphasizing password security: Does your password pass the test?

　　Linux SSH security policy 3: restrict IP login

If you can connect to your server using a fixed IP address, you can set to allow only a specific IP address to log on to the server. For example, I log on to the server through my own VPN. The settings are as follows:

# Edit/etc/hosts. allow

Vi/etc/hosts. allow

# For example, you can only log on to 123.45.67.89.

Sshd: 123.45.67.89

　Linux SSH security policy 4: Use a certificate to log on to SSH

It is safer to use a certificate than to log on with a password. Tap water coffee has written a detailed tutorial, with the consent of it, reproduced as follows:

Configure SSH certificate login verification for CentOS

Help the company's network administrator remotely detect the email server, a CentOS 5.1 instance, and use OpenSSH for remote management. When checking the security log, we found that there were a bunch of IP addresses every day to guess the password over the past few days. It seems that it is better to change the logon authentication method to certificate authentication.

In case of protection, a VNC is enabled temporarily, so that sshd cannot be restarted without configuration. (Later I found it redundant, as long as I open a putty first and don't close it)

Follow these steps:

1) first add a maintenance account: msa

2) then su-msa

3) ssh-keygen-t rsa

After specifying the key path and entering the password, the public key and private key are generated in/home/msa/. ssh/: id_rsa id_rsa.pub

4) cat id_rsa.pub> authorized_keys

As to why the file should be generated, this is what is written in sshd_config.

Then chmod 400 authorized_keys will be slightly protected.

5) use psftp to pull id_rsa back to the local machine, and then kill id_rsa and id_rsa.pub on the server.

6) configure/etc/ssh/sshd_config

Protocol 2

ServerKeyBits 1024

PermitRootLogin no # prohibit root login. it has nothing to do with this article.

# There is nothing to change in the following three lines. just remove the default # comment.

RSAAuthentication yes

PubkeyAuthentication yes

AuthorizedKeysFile. ssh/authorized_keys

PasswordAuthentication no

PermitEmptyPasswords no

7) restart sshd

/Sbin/service sshd restart

8) convert the certificate format to putty.

Run puttygen to convert id_rsa to the ppk certificate file of putty

9) configure putty login

In connection -- SSH -- Auth, click Browse and select the certificate you just converted.

Then fill in auto login username in connection-Data. for example

Enter the server IP address in the session. if you are happy, you can save it.

10) solve the problem

When this step is done, it is very likely that there will be an empty joy. at this time, I am eager to log on, maybe not to go in:

No supported authentication methods available

You can modify sshd_config

PasswordAuthentication no is temporarily changed:

PasswordAuthentication yes and restart sshd

In this way, you can log on successfully. after logging out, change the value of PasswordAuthentication to no and restart sshd.

After you log on, you will be asked about the password of your key file, and you will be able to log in happily.

For the psftp command, add the-I parameter and specify the certificate file path.

If you modify the preceding configuration on a remote server, be sure to exercise caution in each step and avoid errors. If the configuration is incorrect and the SSH connection fails, the problem may be solved.

Basically, after the above four points are configured, SSH access in Linux is safer. Of course, security and insecurity are relative. you should regularly check the server log to detect and eliminate potential risks in time.