Five suggestions for enhancing SSH Security

Five suggestions for enhancing SSH Security
GuideWhen you view your SSH service logs, you may find some malicious and attempted logins. There are five general suggestions (and some special policies) to make your OpenSSH session more secure.Enhanced Password Logon

It is easy to log on with a password because you can log on from any machine anywhere. However, they are also fragile in the face of violent attacks. Try the following policies to enhance your Password Logon.

• Use a password generation tool, such as pwgen. Pwgen has several options. The most useful option is the password length option (for example, pwgen 12 generates a 12-character password)
• Do not use the password again. Ignore all suggestions for not writing down your password, and keep all your logon information in one notebook. If you don't trust my advice, you can always trust Bruce Schneier, the security authority. If you are careful enough, no one can find your notebook, so that you can not be attacked on the Internet.
• You can add some additional protection measures for your logon notepad, such as replacing the character or adding new characters to mask the logon password on the notebook. Use a simple and memorable rule, such as adding two additional random characters to your password or replacing it with a single simple character, such as "#" with "*".
• Enable a non-default listening port for your SSH service. Yes, this is an old-fashioned suggestion, but it does work. Check your logon. It is very likely that port 22 is a commonly attacked port, while other ports are rarely attacked.
• Use Fail2ban to dynamically protect your server from brute force attacks.
• Use an uncommon user name. Do not allow the root user to log on remotely and avoid the user name being "admin ".

Resolving Too Authentication Failures Error

When I fail to log on to my ssh server and the error message "Too authentication failures for carla" is displayed, I am very sorry. I know I should not mind, but this error is really inconspicuous. Moreover, as my smart grandmother once said, the sense of pain cannot solve the problem. The solution is in your (client)

~/.ssh/config

File Settings force password login. If this file does not exist, create one first

~/.ssh/

Directory.

$ mkdir ~/.ssh$ chmod 700 ~/.ssh

And then create

~/.ssh/confg

File, enter the following line, and replace the HostName with your own remote domain name.

HostName remote.site.comPubkeyAuthentication=no

This error occurs when you log on to another server using ssh on a Linux machine. the ssh directory stores too many private key files, while the ssh client does not specify the-I option, by default, these private keys will be used to log on to the remote server one by one before the system will prompt the password to log on. If these private keys do not match the remote host, it will obviously trigger such an error or even reject the connection. Therefore, this article forces the use of a password to log on by disabling the local private key-obviously this is not desirable. If you do want to avoid using the private key to log on, then you should log on with the-o PubkeyAuthentication = no option. Obviously, this article is in conflict with the next two, so ignore this article .)

Use Public Key Authentication

Public Key Authentication is much safer than Password Logon because it is not affected by brute force password attacks, but it is not convenient because it depends on RSA key pairs. First, you need to create a public/private key pair. Next, place the private key on your client computer and copy the public key to the remote server you want to log on. You can only log on to a remote server from a computer with a private key. Your private key is as sensitive as your home key. Anyone who gets the private key can get your account. You can add a password to your private key to add some enhanced protection rules.

It is a good method to manage multiple users using RSA key pairs. When a user leaves, he or she can cancel the login by deleting his or her public key from the server.

In the following example, a new 3072-bit key pair is created, which is safer than the default 2048-bit key pair and has a unique name, in this way, you can know which server it belongs.

$ ssh-keygen -t rsa -b 3072 -f id_mailserver

Create two new keys as follows,

id_mailserver

And

id_mailserver.pub

id_mailserver

It's your private key-do not spread it! Use now

ssh-copy-id

Command to securely copy your public key to your remote server. You must ensure that there is an available SSH logon method on the remote server.

$ ssh-copy-id -i  id_rsa.pub user@remoteserver/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installeduser@remoteserver's password:Number of key(s) added: 1Now try logging into the machine, with:   "ssh 'user@remoteserver'"and check to make sure that only the key(s) you wanted were added.

Ssh-copy-id ensures that you do not accidentally copy your private key. Copy the logon command from the above output and remember to enclose the single quotes to test your new key logon.

$ ssh 'user@remoteserver'

It will log on with your new key. If you set a password for your private key, it will prompt you to enter it.

Cancel Password Logon

Once you have tested and verified that your public key can be logged on, you can cancel the Password Logon so that your remote server will not be attacked by a brute force password. SettingsYour remote server

/etc/sshd_config

File.

PasswordAuthentication no

Then restart the SSH daemon on the server.

Set aliases-this is quick and cool

You can set a common alias for your remote logon to replace the command entered during logon, for example

ssh -u username -p 2222 remote.site.with.long-name

You can use

ssh remote1

On your client machine ~ The/. ssh/config file can be set as follows:

Host remote1HostName remote.site.with.long-namePort 2222User usernamePubkeyAuthentication no

If you are using the public key to log on, you can refer to this:

Host remote1HostName remote.site.with.long-namePort 2222User usernameIdentityFile  ~/.ssh/id_remoteserver

OpenSSH documentation is very long and detailed, but after you have mastered the basic SSH usage rules, you will find it very useful and contains many cool effects that can be achieved through OpenSSH.

From: https://linux.cn: 443/article-7683-1.html

Address: http://www.linuxprobe.com/five-safety-advice.html