Linux Advanced SSH Security tips

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

1, modify the SSH listening port

By default, SSH Listener connection Port 22 allows an attacker to see whether the host is running an SSH service using port scanning software, and modifying the SSH port to a port greater than 1024 is a wise choice because most port scanning software (including nmap) does not scan the high port by default.

Open the/etc/ssh/sshd_config file and look for lines like the following:

Port 22

To modify the port number and restart the SSH service:

/etc/init.d/ssh restart

2. Allow SSH protocol version 2 only

With two SSH protocol versions, SSH protocol version 2 is more secure, SSH protocol version 1 has security issues, including man-in-the-middle attacks (man-in-the-middle) and injection (insertion) attacks. Edit the/etc/ssh/sshd_config file and look for lines like the following:

Protocol 2,1

Amended to

Protocol 2

3, only allow specific users to login via SSH

You're not one to allow the root user to log in via SSH, because this is a huge unnecessary security risk, if an attacker gets root access to your system, relative to his access to a normal user rights can cause greater damage, configure the SSH server does not allow root users through SSH login, Look for lines such as the following:

Permitrootlogin Yes

Modify Yes to No, and then restart the service. Now, if you want to use privileged users, you can log in to another user and then switch to root.

Creating a virtual user with no actual permissions is a wise choice to log on to SSH with this user, even if the user is cracked and will not cause any damage, when creating this user, make sure it belongs to the wheel group, because then you can switch to privileged users.

If you want a list of users to be able to log in via SSH, you can specify them in the Sshd_config file, for example: I want users Anze, Dasa, KimY to log in via SSH, and I 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 (mine is/etc/ssh-banner.txt) and enter any text messages you want, such as:

*this is a private SSH service. You are 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

Cancel the comment "Remove the #" and modify the path to your custom SSH banner text file.

5. Use DSA Public key authentication

Instead of using user name and password to authenticate SSH, you can use the DSA public key authentication, notice you can use the login name, also can use the DSA public key authentication, use DSA public key authentication can prevent your system to suffer from dictionary attack, because you do not need to use login name and password login SSH service, Instead, a pair of DSA keys, a public key, and a private key are required to save the private key on your local machine and place the public key on the server. When you initiate an SSH login session, the server checks the key, and if they match, you can go directly to the shell, and if they do not match, your connection will be disconnected automatically.

In this example, the private computer is called ' Workstation 1 ', and the server is called ' server 1 '. I have the same home directory on two machines, if the server and the home directory on the client are different will not work, implementation, you need to create a pair of keys on your personal computer, command: ~$ ssh-keygen-t DSA, it will require you to enter a secret password for the private key, but you can leave it blank , because this is not a recommended practice. The key pair is created: your private key is in ~/.SSH/ID_DSA, and your public key is in. Ssh/id_dsa.pub.

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

~$ Cat. Ssh/id_dsa.pub SSH-DSS AAAAB3NZAC1KC3MAAACBAM7K7VKK5C90RSVOHIHDUROVYBNGR7YEQTRDFFCUVWMWC JYDUSNGAIC0OZKBWLNMDU+Y6ZOJNPOTTPNPEX0KROH79MAX8NZBBD4AUV91LBG7Z604ZTDR lzvsfhci/fm4yrohge0fo7fv4lgcuilqa55+ qp9vvco7qybdipdunv0laaaafqc/9iljqii7n M7akxibpdrqwknypqaaaieaq+ojc8+oyioexcw8qcb6ldibxjv0ut0rrutfvo1bn39cawz5pu Fe7eplmr6t7ljl7jdkfea5de0k3wds 9/RD1TJ6UFQSRC2QPZBN0P0J89LPIJDMMSISQQAKO4M2FO2VJCGCWVSGHIOD0AMRC7NGIE6BTA NIHBBQRI10RGL5GH4AAACAJJ1/RV7IKTOYUVYQV3BAZ3JHOAF+H/DUDTX+WUTUJPL+TFDF61RB woqraruhfrf0tu/rx4oozzadlqovafqrdnu/ NO0ZGE+WVXDD4OL1YMULRKQP8VC20WS5MLVP 34fst1amc0ynebp28eqi0xpefud0ixzztxthvlzia1/nuzy= anze@station1.example.com

If the file ~/.ssh/authorized_keys already exists, attach the above content to the file below. All that's left is to set the correct permissions on the file:

~$ chmod ~/.ssh/authorized_keys

Now, configure the Sshd_config file with the DSA key authentication to make sure you remove the comments from the following three lines:

Rsaauthentication Yes

Pubkeyauthentication Yes

Authorizedkeysfile%h/.ssh/authorized_keys

Restart the service, and if your configuration is correct, you can now ssh to your server and go directly to your home directory without any interaction action (such as entering a username and password).

If you only want to use DSA authentication log in, make sure you cancel the annotation in Sshd_config and modify the Passwordauthentication line, change Yes to No:

Passwordauthentication No

Any person who does not have a public key on the server tries to connect to your SSH service, and it is rejected, displaying the following denial of message:

Permission denied (PublicKey).

6. Use TCP wrappers to allow only the specified host to connect

This is useful if you want to allow only specific hosts on your network to connect to your SSH service, but do not want to use or mess with your iptables configuration, and you can use TCP wrappers. In this example, the TCP package for sshd, I will create a rule that allows local subnets 192.168.1.0/24 and remote 193.180.177.13 to connect themselves 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, and then the TCP wrappers looks/etc/hosts.allow to see if there are rules that allow the service specified by the host service, I will be in/etc Create a rule in/hosts.deny, as follows:

Sshd:all

This means that all hosts are denied access to the SSH service by default, otherwise all hosts can access the SSH service because TCP wrappers first in Hosts.deny, and any host can connect if there are no rules for blocking SSH service.

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/24 and 193.180.177.13 can access the SSH service, and other hosts are disconnected when they are connected to the landing prompt and receive an error message as follows:

Ssh_exchange_identification:connection Closed by remote host

7, use Iptables to allow specific host connection

As a substitute for TCP wrappers, you can use Iptables to restrict SSH access (but you can use this two at the same time), here's a simple example of 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

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

~# iptables-a input-p TCP--dport 22-j DROP

Save your new rule, your task is done, the rules will come into 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 be connected within a specific time span and not be connected at other times. You can use the/second,/minute,/hour, or/day switches in any of the following examples.

For the first example, if a user enters the wrong password, the lock is not allowed to access the SSH service within a minute, so that each user can only attempt to log in within a 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, setting iptables only allows host 193.180.177.13 to connect to the SSH service, Iptables allows the host to attempt to log on once every minute after attempting three unsuccessful landings:

~# iptables-a input-p tcp-s 193.180.177.13-m State--syn--state NEW--dport 22-m limit--limit 1/minute T 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 techniques are not difficult to grasp, but they are a powerful means of protecting your SSH service, and paying a little for a good night's sleep.