In the previous note, we successfully set up the SSH service on the server without any configuration. In this note we will configure our SSH service in terms of security to make our server more robust.

Modify the port

By default, SSH monitors port 22. Many malicious scripts will forcibly log in to this port, that is, try to guess the account password through the password book. Therefore, when configuring SSH access network security, you must first customize the SSH listening port. (A lot of configurations, such as Fail2BAN, firewall, DMZ, IDS, etc. are beyond my current knowledge to truly secure SSH access to the network…)

configuration

  1. Add SSH custom configuration files on the server:/etc/ssh/sshd_config.d/custom.conf
  2. Modify SSH listening port in configuration file:Port 19512
  3. The SSH service on the server reads the configuration again:sudo systemctl reload sshd
  4. Port specified for client login:ssh -p 19512 <user_name>@<IP>

test

After the SSH listening port of the server is changed, the client cannot log in unless the correct port is specified.

User permissions

By default, all users on the server have the SSH login permission. You can create a user group on the server and put only the users who really need SSH login into the user group, which is convenient for hierarchical management of rights and quick locating of problems.

configuration

  1. Add AllowGroups ssh_group to the custom configuration file /etc/ssh/sshd_config.d/custom.conf

  2. Run the sudo systemctl reload SSHD command to re-read the configuration

  3. Create a user group with SSH login permission on the server

    1. Create a user group:sudo groupadd ssh_group
    2. Add a user to a user group:sudo gpasswd -a <user_name> ssh_group
    3. Check whether the vm is successfully added:sudo getent group ssh_group

test

As shown in the following figure, the user fails to log in to the system through SSH for the first time because he is not added to the user group with SSH login permission. A user can log in to the system again only after the server is added to the SSH login user group.

Key management

Let’s review the overall structure of a key login: the user places the private key that indicates identity locally and the public key that authenticates identity on the server. Except for the first time when the public key is placed, the user’s identity is verified by the server account password, and then the private key and public key are paired to verify the identity. That is, you can simply think of the key as corresponding to the user account password.

This presents a problem: although a user has only one account and password on the server, it can create countless key pairs, each of which can match the password of the user’s account on the server. This is like having multiple passwords for one account, which is obviously not conducive to login security management. Therefore, the first step in building many SSH key management systems is to centrally manage keys.

Of course, in actual SSH applications, unified key management must be implemented, user access permission must be granted and revoked, and corresponding process specifications should be formulated for each remote login application and termination.

To further improve security, SSH can introduce a digital Certificate Authority (CA) and manage SSH based on certificates.

Next, we configure a very simple SSH key management system: the key is centrally managed by the root user

configuration

  1. Create a unified user key management directory as user root:sudo mkdir -v /etc/ssh/user_keys
  2. Create a subfolder for each user with remote login permission and name it with the user name:sudo mkdir -v /etc/ssh/user_keys/<user_name>
  3. Will each user’s public key fileauthorized_keysMove to the corresponding folder:sudo cp -ai /home/<user_name>/.ssh/authorized_keys /etc/ssh/user_keys/<user_name>/
  4. In the custom configuration file/etc/ssh/sshd_config.d/custom.confaddAuthorizedKeysFile /etc/ssh/user_keys/%u/authorized_keys
  5. The SSH service on the server reads the configuration again:sudo systemctl reload sshd

validation

We create the key test and send it to the server using the steps in the previous note: /home/

/.ssh/authorized_keys

You can see that the key has been successfully transferred to the server user folder

Next we log in using the newly created key:

You can find that the key login fails, prompting you to use the password to log in. This is because the user login keys are centrally managed by root in /etc/ssh/user_keys/%u/authorized_keys. The new key takes effect only after root copies the new key to the corresponding folder.

You can see that the user’s newly added key is successfully copied to /etc/ssh/user_keys/%u/authorized_keys. Next, we try to log in with the newly added test key again, and find that the login is successful:

conclusion

In this note, we made our server a little more “robust” by configuring custom ports, access user groups, and centralized key management for the SSH service on the server. While these configurations are at best “toys” relative to real SSH security, it’s an interesting attempt to incorporate security into the development process 🙂