保护系统上的 SSH 访问的八种方法

SSH。我们了解它。我们喜欢它。我们必须使用它。

我将带您完成八个步骤，以更好地帮助您保护网络上的 SSH 服务。我想我们都意识到 SSH 的重要性。它允许我们连接到 Linux 设备、Unix 服务器、网络设备，有时甚至是 Windows 设备。我不会试图向您推销 SSH 的使用频率或它的重要性。我将提供一份可靠的清单，您可以使用它来确保您环境中的 SSH 服务已锁定。

1.备份配置文件

首先，在进行重大更改之前备份配置文件。这是一条常见的建议，但却是一条实实在在的建议。这很简单，只需片刻，并且可以在编辑文件时万一出错时保护您。谁没有在 Vim 中犯过错误呢？

# cp /etc/ssh/sshd_config ~/sshd_config_original

瞧，这并不是那么糟糕。

挑战——在进行重大编辑之前，您是否始终备份配置文件？

2. 设置横幅消息

诚然，这与其他任何事情一样，都是出于法律要求，但同样，此设置只需要片刻。实际上，您也可以在横幅消息中提供一些相当不错的信息。首先，我们将/etc/issue.net使用 Vim 在文件中写入横幅消息。然后我们将打开文件sshd_config并告诉它使用内容issue.net作为横幅。

# vim /etc/issue.net

Warning! Authorized use only.
This server is the property of MyCompanyName.com

[ 你可能还喜欢： 使用 sshpass 在 Linux 中实现 SSH 密码自动化]

显然，您需要想出一些与您的组织相关的特定信息。删除issue.net文件中已有的任何信息。

接下来，告诉 SSH 使用横幅消息。在 Vim 中打开文件，找到Bannersshd_config这一行。你还记得在 Vim 的命令模式下可以使用斜杠字符来搜索文件吗？例如，/banner

# vim /etc/ssh/sshd_config

找到#no default banner path这一行，然后取消注释下一行（即Banner）。

# no default banner path
Banner /etc/issue.net

使用:wq在 Vim 中保存更改，然后重新启动 SSH 服务：

# systemctl restart sshd

注意：从现在起，我不会提醒你重启 SSH。每次你对配置文件进行更改时，都必须重启该服务。

挑战——横幅信息在您网络上的所有 SSH 设备上是否一致？

3. 防止使用空密码

This seems like a no-brainer, but empty passwords are clearly a bad idea. You may have other utilities, such as Pluggable Authentication Modules (PAM), regulating your regular passwords, but it's also a good idea to make sure SSH enforces responsible security settings, too.

Open the /etc/ssh/sshd_config file in Vim, and then find the line that reads PermitEmptyPasswords. Uncomment it, and replace the yes value with no.

PermitEmptyPasswords no

That's it.

4. Prevent the root user from crossing the network via SSH

The idea here is pretty straightforward. Send standard user credentials across the network instead of root credentials. Once you've established your SSH connection using a standard user account, use su or sudo to elevate your privileges.

Open the SSH configuration file, and then uncomment the PermitRootLogin line. Edit the setting from yes to no.

PermitRootLogin no

Challenge - your organization has embraced sudo, right?

5. Whitelist specific user accounts

If you're already preventing the use of the root user account across SSH, why not go a step further and explicitly state which users can connect to the server? Perhaps you have a regular non-root admin account you use or one that's already configured with sudo privileges.

In the SSH configuration file, add the following line (it's not in there by default):

AllowUsers user1

I'd put it near the PermitRootLogin no setting.

By the way, you can actually filter with all of the following settings: AllowUsers, DenyUsers, AllowGroups, DenyGroups. I wrote them in that order on purpose—that's the order in which they are processed. You can discover more information on the man page for sshd_config.

Challenge - be careful about exactly who is authorized.

Note: You can limit connections via iptables, too.

6. No more port 22

Another common change is to configure SSH to listen on a different port than the standard 22/tcp that we've all memorized. There's already an entry in the sshd_config file.

You can comment out the default port setting and add another line, as I've done below:

#Run SSH on a non-standard port
#Port 22
Port 2222

I suspect many folks use 2222 as the replacement port number, so you may want to standardize on something a little more unique.

You must remember to append the new non-standard port number to your SSH connection attempts from this point on. For example:

# ssh -p 2222 user1@10.1.0.42

Challenge - do you have the same non-standard port number configured for all your SSH destinations? Consistency will make your life much easier.

7. Time's up!

The next tip deals with timing out connections. The ClientAliveInterval manages idle SSH connections. The server sends a message to the client and expects a response. The ClientAliveInterval is the space of time between the messages. The ClientAliveCountMax defines how many times the server will do this before deciding the client isn't really there anymore. At that point, the connection is dropped.

Here is an example configuration that checks every 60 seconds and will do so three times:

ClientAliveInterval 60
ClientAliveCountMax 3

Edit these values to something that makes sense for your environment.

Note: If you're using SSH to tunnel for other connections, you may need to ensure that the interval is long enough to properly support whatever other applications are using it.

There's a ServerAliveInterval value that you can configure on the client-side, too. This allows clients to drop connections to non-responsive SSH servers.

8. Here's the key

One of the most common security settings for SSH these days is key-based authentication. Through the years that I've taught Linux, this authentication method has become more and more common. In fact, I wouldn't attempt a Red Hat admin exam without feeling confident in this process. Fortunately, it's not difficult.

Let's do a quick review. Key-based authentication uses asymmetric cryptography. That means there are two keys, different but mathematically related to each other. One is private and never sent across the network. The other is public and may be transferred across the network. Because the keys are related, they can be used to confirm identities—identities such as SSH authentication attempts.

You'll need to generate the key pair on the local SSH client computer and then transfer the public key across the network to the destination SSH server. In other words, the keys will identify you on your admin workstation. Once this configuration is in place, you are no longer challenged for a password when you establish an SSH connection.

The process only requires a few steps.

First, generate the key pair:

# ssh-keygen

The keys are stored in your home directory in a hidden directory named .ssh, and the default key names are id_rsa (private key) and id_rsa.pub (public key).

Next, send the user1 public key across the network to the destination SSH server located at 10.1.0.42:

# ssh-copy-id user1@10.1.0.42

Finally, test the connection:

# ssh user1@10.1.0.42

Notice that you are not challenged for a password.

Since you have now embraced key-based authentication, you can edit the sshd_config file to prevent any logins based on passwords. Once you configure this setting, only key-based authentication will be accepted.

Edit these two lines in the file:

PasswordAuthentication no
PublicKeyAuthentication yes

[ Want to learn more about security? Check out the IT security and compliance checklist. ] 

Wrap up

I have listed several common but effective SSH configurations to help you better secure your environment. Remember, with security, no one setting is likely to protect your devices. The goal is layers of security, the combination of which helps to mitigate security threats. I strongly suggest that you carefully organize your keys if you implement key-based authentication. You might also consider using a centralized /etc/ssh/sshd_config file to maintain consistent security configurations on your SSH servers. Don't forget to restart SSH any time you change the configuration file.