Private Instructions for enhancing OpenSSH security on Ubuntu 20.04

[trungduc198]

Prerequisites for enhancing OpenSSH security on Ubuntu 20.04​

To carry out this tutorial, you need to prepare a few things such as:

• An Ubuntu 20.04 server with OpenSSH installed and enabled.
• One user account non-rootbut with sudo.

When ready, log in to your server and refer to the instructions below.

Enhancing OpenSSH security on Ubuntu 20.04 is one of the effective ways to protect your system against security threats. However, to ensure maximum security for your data and applications, using a VPS service is a perfect choice.

Step 1 – Enhance general security​

First, you need to do some configuration to improve the overall security of your SSH server.

You will need to edit the main OpenSSH configuration file g /etc/ssh/sshd_configto adjust the security options. Therefore, before starting you should create a backup of the current configuration file so that you can restore it if something goes wrong during configuration.

Create a backup copy of the file using the command cpbelow:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

This command will save a backup copy of the file to /etc/ssh/sshd_config.bak. If you do not want to save at this path, you can replace the paragraph /etc/ssh/sshd_config.bakin the above command with the path and file name you want to backup as you like.

Next, let's look at the default OpenSSH configuration options set up in /etc/ssh/sshd_config. Use the following command:

sudo sshd -T

This command will run the OpenSSH server in extended test mode, which will validate the entire configuration file and print out the configuration values.

You can now open the configuration file with nano or your favorite text editor to start implementing security configuration measures:

sudo nano /etc/ssh/sshd_config

When editing configuration files, some default options are set to comments with #preceding characters and these options will not run. To edit or enable this configuration option, you just need to delete the character #at the beginning of that line and these options will work.

The first step you need to take is to disable logging in via SSH with your root. Go to the configuration section PermitRootLoginand change the value to no, or if this command is being commented out, you can delete the sign #in front.

PermitRootLogin no

This option will prevent an attacker from logging directly into your server with root. At the same time, users are also recommended to increase protection by using the system with a non-root user and only use it sudowhen absolutely necessary.

Next, you can limit the maximum number of login attempts for a specific login session by changing the value in MaxAuthTries:

MaxAuthTries 3

Typically, 3 is the most suitable value, but you may want to set this value higher or lower as desired to ensure your SSH security.

Additionally, you can limit the user login time after connecting to your SSH server by configuring the login timeout:

LoginGraceTime 20

The value specified in the configuration file is in seconds. Reducing this value will help prevent some denial of service (DoS) attacks.

If you previously configured SSH keys to authenticate instead of using passwords, disable SSH password authentication to prevent password leaks:

PasswordAuthentication no

If you have not configured SSH keys for authentication, there is no need to disable this authentication.

Additionally, to increase password-related security, you can disable authentication with a blank password. This will prevent login if the user's password is changed to null:

PermitEmptyPasswords no

Typically, SSH will be configured with a public key authentication method. However, the OpenSSH server also supports a variety of authentication methods, some of which are enabled by default. If not needed, you can disable them to reduce the risk of SSH server attacks:

ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no

If you want to know more about other additional authentication methods in SSH, you can find documents on the following keywords:

• Challenge Response Authentication.
• Kerberos Authentication.
• GSSAPI Authentication.

After turning off verification methods users can also consider the feature X11 forwarding, which allows displaying graphical applications remotely over an SSH connection but this is usually not used so turn it off if you don't. use:

X11Forwarding no

In addition, the OpenSSH server also allows connecting clients to transmit custom environment variables. For example, a client may attempt to reset $PATHa certain application. However, like X11 forwarding, they are not used very often, so you can turn this option off:

PermitUserEnvironment no

Note : If you decide to disable this option by setting it to no, you will also need to comment out all references in the section AcceptEnvby adding a symbol #to the beginning of the option's line.
Next, you can disable some other options related to tunnelingand forwardingif you are not using them on your server:

AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no

Finally, you can turn off the header SSH verbosethat's enabled by default, as it shows a lot of information about your system, such as the operating system version:

DebianBanner no

Note: This option (In some cases) may not be available in the configuration file, so you may need to add this command manually.
Now that you've configured some basic things, you can save the file by pressing Ctrl + X, Ythen Enterto save and close the configuration file.

Now, you need to check to see if the configuration file you just changed above has any syntax errors or errors by running SSH in test mode:

sudo sshd -t

If your configuration file has valid syntax, nothing will be output. In case there is a syntax error, the output will output that error and point out the error so you can open the configuration file and correct it.

Once you are satisfied with your configuration file, you can reboot sshdto systemctlapply the new settings with the command:

sudo systemctl reload sshd.service

So you have successfully increased the overall security of your OpenSSH server. Next step, you will create a list of IP addresses to limit the users that can log in to your server.

Step 2 – Set up a list of IPs that allow access​

By setting up a list of IP addresses that allow access, you can ensure that only imports from allowed IP addresses can be approved, helping to minimize the risk of intrusion in the event of unauthorized access. Your private key or password is leaked.

Typically, you only log into your server from a small number of known and trusted IP addresses. For example : Internet connection at home, business VPN or datacenter , secure server systems, etc.

Note: Be sure to identify the correct IP addresses to add to your whitelist and make sure they are not reserved or frequently changed.
You can determine the current IP address to which you are connecting to your server using the command "w":

w

This command will produce an output like this:

Output
14:11:48 up 2 days, 12:25, 1 user, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
your_username pts/0 203.0.113.1 12:24 1.00s 0.20s 0.00s w

Here, you can locate your user account in the list and note down the connection IP address. As here, the IP address is 203.0.113.1.

To start setting up your IP address whitelist, open the OpenSSH server configuration file in nano or your favorite text editor:

sudo nano /etc/ssh/sshd_config

You can set up an IP address whitelist using the configuration section AllowUsers, which limits user authentication based on username or IP address.

Depending on your system configuration and requirements, you can apply the most appropriate configuration directives to allow IP addresses that are allowed to connect. Below are examples to help you determine the most appropriate configuration.

Restrict all users to a specific IP address:

AllowUsers *@203.0.113.1

Restrict all users to a specific IP address range using CIDR (Classless Inter-Domain Routing) notation:

AllowUsers *@203.0.113.0/24

Restrict all users to a specific range of IP addresses (Use wildcards):

AllowUsers *@203.0.113.*

Restrict all users to specific IP addresses and address ranges:

AllowUsers *@203.0.113.1 *@203.0.113.2 *@192.0.2.0/24 *@172.16.*.1

Disallow all users except those named after specific IP addresses:

AllowUsers sammy@203.0.113.1 alex@203.0.113.2

Restrict a specific user to a specific IP address, while still allowing all other users to log in without restrictions:

Match User ashley
AllowUsers ashley@203.0.113.1

Note : In the OpenSSH configuration file, all configurations contained within the block Matchwill only apply to connections that match the criteria, regardless of indentation or carriage return. This means you have to be careful and ensure that configurations set to apply globally don't accidentally get placed in blocks Match. Always place all blocks Matchat the end of the configuration file to avoid discrepancies while applying configuration criteria.
After completing the configuration, add this criteria to the bottom of your OpenSSH server configuration file:

AllowUsers *@203.0.113.1

Then save and close the file with Ctrl + X, Ythen Enter. And check the syntax of the configuration file with the command:

sudo sshd -t

If no errors appear, you can restart OpenSSH to apply your changed configuration above with the command:

sudo systemctl reload sshd.service

So in this step, you have finished setting up an IP address whitelist on your OpenSSH server. Next, you will restrict a user's shell to limit the commands they are allowed to use.

Step 3 – Limit user shell interactions​

In addition to providing remote shell access, SSH is also great for transferring files and other data, for example via SFTP (Secure File Transfer Protocol). However, you don't always want to give users full shell access when they just need to perform file transfers.

In OpenSSH server there are many ways for you to configure to restrict the shell environment of specific users. For example, in this tutorial, you will configure to create users that can only use SFTP.

First, you can use commands /usr/sbin/nologinto disable interactions for specific user accounts.

To create a new user with nologinthe shell, use the following command:

sudo adduser --shell /usr/sbin/nologin alex

You can rename alex to the username you want to create. In addition, you can also change the shell of an existing user to nologin, for example, if the sammy account already exists, use the command:

sudo usermod --shell /usr/sbin/nologin sammy

Now, these accounts will no longer be allowed to log in to the shell, but transferring files or data to these accounts will still work normally. You can try to test it by logging into the accounts that have been converted to nologintest:

sudo su alex

Next, you should combine the use of nologinthe shell and configure some additional options to restrict the user accounts involved.

Proceed to open the OpenSSH configuration file with nanoor text editor of your choice:

sudo nano /etc/ssh/sshd_config

Here, there are 2 configuration options that you can add to the configuration: ForceCommand internal-sftpand ChrootDirectory.

The option ForceCommandwill force the user to execute a specific command upon login. In this case, the command ForceCommandwill execute the command internal-sftp. In this case, the system will launch the SFTP daemon on-premises without needing additional support files or configuration. The purpose is to force users to log in using the SFTP protocol and to create SFTP accounts that can only share files.

And the option ChrootDirectoryis used to limit the file space for a particular user. When used in conjunction with ForceCommand internal-sftp, this will restrict users from being able to access only the folder you specify and prevent them from accessing other folders on the system.

Once you understand these two options, add the users you want to restrict to the configuration file as below:

Match User alex
ForceCommand internal-sftp
ChrootDirectory /home/alex/

Here, the account I limit is Alex, which comes with a limited space that only allows access inside /home/alex/and not elsewhere.

Note: Like I mentioned in step 2, you must be careful and ensure that globally set configurations are not accidentally placed in blocks Match. To avoid errors, blocks Matchshould be placed at the end of the configuration file. image.
After configuration is complete, save the file and check with the command:

sudo sshd -t

If no errors appear, then your configuration file is stable, now restart the SSH service to apply these configurations:

sudo systemctl reload sshd.service

So through step 3, you have set up very restrictive configurations for the alex user account . Specifically disable login and all SFTP activities are limited to that user's home directory. This will help ensure that this account will not be able to access other files on the system.

Step 4 – Some advanced security measures​

In this final step, you will implement various advanced security measures to ensure secure access to your SSH.

OpenSSH server can impose restrictions on a per-key basis. Specifically, these restrictions can be applied to any public key contained in the .ssh/authorized_keys. This capability is especially useful for access control. Additionally, it also allows users without sudo permissions to manage restrictions for their accounts.

Note: This security configuration can only be deployed when applying the SSH public key. For other authentication methods such as password or CA level, this option is disabled.
To proceed with imposing restrictions on the key, open the file .ssh/authorized_keysin nanoor your editor:

nano ~/.ssh/authorized_keys

Another thing to note is that this configuration is applied on a per-key basis. Therefore, users will have to edit each key of each authorize_keys file one by one and do it for all users on the system. This process will be simple if the number of users is very small, however this is not a good idea for large scale with many users, high system complexity.

After opening the file authorized_keys, you will see that each line contains an SSH public key, which may begin with ssh-rsa AAAB …The configuration options you want to add can only be added to the beginning of that key's line, and they will also apply individually. for that key only.

Here are some configuration options that you can refer to:

• no-agent-forwarding: Disable SSH agent forwarding.
• no-port-forwarding: Disable SSH port forwarding.
• no-pty: Disable the ability to allocate tty (Is it a shell or terminal). Meaning the user will not be able to start the shell via an SSH connection.
• no-user-rc: Prevent execution of file ~/.ssh/rc.
• no-X11-forwarding: Disable X11 forwarding (Introduced in step 1).

Based on these options, you can add them to the keys you want to restrict, for example to disable X11 forwarding, or SSH agent, you add to the beginning of that key as follows:

no-agent-forwarding, no-X11-forwarding ssh-rsa AAAB ...

Here ssh-rsa AAAB ...is the key in your system, and the options are added to the beginning of that key. Note that these options only apply to the key you add, to apply to another key, you must also these options must be added to the beginning of that key.

By default, this configuration has the mechanism "allow by default" and "block by exception", of course the reverse can be configured to improve safety.

The second way is to use the option restrict, which will implicitly deny all SSH features for the specific key. You can re-enable the feature using the configuration options outlined above, but without the no-.

For example, to disable all SSH features for a specific key except X11-forwarding, you can use the following configuration:

restrict,X11-forwarding ssh-rsa AAAB...

Here it means that you have turned off everything and only left X11-forwardingthis key. Normally you should use this method to limit locks. You can also add options commandto the key, this is quite similar to ForceCommandstep 3.

For example, to force users to authenticate using a specific key to perform once commandlogged in, you can add the following configuration:

command = "top" ssh-rsa AAAB ...

However, the configuration option commandonly acts as an additional defense method and it should not be relied upon solely to limit SSH user activities, as there may be ways to bypass it.

So the best way is to use both methods, one restrictand then use it commandto make a second defensive wall like below:

restrict,command="false" ssh-rsa AAAB...

The option restrictdisables all interactions, and the option command = "false"acts as a second command line guard in case the option ForceCommandor nologinshell fails.

After completing the configuration, save it and this key configuration file will automatically take effect immediately without having to reload the SSH service. So make sure to check the commands you used before disconnecting from the current SSH login session.

Click to read more...

 

[qudsiabilal799]

th

Prerequisites for enhancing OpenSSH security on Ubuntu 20.04​

To carry out this tutorial, you need to prepare a few things such as:

• An Ubuntu 20.04 server with OpenSSH installed and enabled.
• One user account non-rootbut with sudo.

When ready, log in to your server and refer to the instructions below.

Enhancing OpenSSH security on Ubuntu 20.04 is one of the effective ways to protect your system against security threats. However, to ensure maximum security for your data and applications, using a VPS service is a perfect choice.

Step 1 – Enhance general security​

First, you need to do some configuration to improve the overall security of your SSH server.

You will need to edit the main OpenSSH configuration file g /etc/ssh/sshd_configto adjust the security options. Therefore, before starting you should create a backup of the current configuration file so that you can restore it if something goes wrong during configuration.

Create a backup copy of the file using the command cpbelow:


This command will save a backup copy of the file to /etc/ssh/sshd_config.bak. If you do not want to save at this path, you can replace the paragraph /etc/ssh/sshd_config.bakin the above command with the path and file name you want to backup as you like.

Next, let's look at the default OpenSSH configuration options set up in /etc/ssh/sshd_config. Use the following command:


This command will run the OpenSSH server in extended test mode, which will validate the entire configuration file and print out the configuration values.

You can now open the configuration file with nano or your favorite text editor to start implementing security configuration measures:


When editing configuration files, some default options are set to comments with #preceding characters and these options will not run. To edit or enable this configuration option, you just need to delete the character #at the beginning of that line and these options will work.

The first step you need to take is to disable logging in via SSH with your root. Go to the configuration section PermitRootLoginand change the value to no, or if this command is being commented out, you can delete the sign #in front.


This option will prevent an attacker from logging directly into your server with root. At the same time, users are also recommended to increase protection by using the system with a non-root user and only use it sudowhen absolutely necessary.

Next, you can limit the maximum number of login attempts for a specific login session by changing the value in MaxAuthTries:


Typically, 3 is the most suitable value, but you may want to set this value higher or lower as desired to ensure your SSH security.

Additionally, you can limit the user login time after connecting to your SSH server by configuring the login timeout:


The value specified in the configuration file is in seconds. Reducing this value will help prevent some denial of service (DoS) attacks.

If you previously configured SSH keys to authenticate instead of using passwords, disable SSH password authentication to prevent password leaks:


If you have not configured SSH keys for authentication, there is no need to disable this authentication.

Additionally, to increase password-related security, you can disable authentication with a blank password. This will prevent login if the user's password is changed to null:


Typically, SSH will be configured with a public key authentication method. However, the OpenSSH server also supports a variety of authentication methods, some of which are enabled by default. If not needed, you can disable them to reduce the risk of SSH server attacks:


If you want to know more about other additional authentication methods in SSH, you can find documents on the following keywords:

• Challenge Response Authentication.
• Kerberos Authentication.
• GSSAPI Authentication.

After turning off verification methods users can also consider the feature X11 forwarding, which allows displaying graphical applications remotely over an SSH connection but this is usually not used so turn it off if you don't. use:


In addition, the OpenSSH server also allows connecting clients to transmit custom environment variables. For example, a client may attempt to reset $PATHa certain application. However, like X11 forwarding, they are not used very often, so you can turn this option off:


Note : If you decide to disable this option by setting it to no, you will also need to comment out all references in the section AcceptEnvby adding a symbol #to the beginning of the option's line.
Next, you can disable some other options related to tunnelingand forwardingif you are not using them on your server:


Finally, you can turn off the header SSH verbosethat's enabled by default, as it shows a lot of information about your system, such as the operating system version:


Note: This option (In some cases) may not be available in the configuration file, so you may need to add this command manually.
Now that you've configured some basic things, you can save the file by pressing Ctrl + X, Ythen Enterto save and close the configuration file.

Now, you need to check to see if the configuration file you just changed above has any syntax errors or errors by running SSH in test mode:


If your configuration file has valid syntax, nothing will be output. In case there is a syntax error, the output will output that error and point out the error so you can open the configuration file and correct it.

Once you are satisfied with your configuration file, you can reboot sshdto systemctlapply the new settings with the command:


So you have successfully increased the overall security of your OpenSSH server. Next step, you will create a list of IP addresses to limit the users that can log in to your server.

Step 2 – Set up a list of IPs that allow access​

By setting up a list of IP addresses that allow access, you can ensure that only imports from allowed IP addresses can be approved, helping to minimize the risk of intrusion in the event of unauthorized access. Your private key or password is leaked.

Typically, you only log into your server from a small number of known and trusted IP addresses. For example : Internet connection at home, business VPN or datacenter , secure server systems, etc.

Note: Be sure to identify the correct IP addresses to add to your whitelist and make sure they are not reserved or frequently changed.
You can determine the current IP address to which you are connecting to your server using the command "w":


This command will produce an output like this:


Here, you can locate your user account in the list and note down the connection IP address. As here, the IP address is 203.0.113.1.

To start setting up your IP address whitelist, open the OpenSSH server configuration file in nano or your favorite text editor:


You can set up an IP address whitelist using the configuration section AllowUsers, which limits user authentication based on username or IP address.

Depending on your system configuration and requirements, you can apply the most appropriate configuration directives to allow IP addresses that are allowed to connect. Below are examples to help you determine the most appropriate configuration.

Restrict all users to a specific IP address:


Restrict all users to a specific IP address range using CIDR (Classless Inter-Domain Routing) notation:


Restrict all users to a specific range of IP addresses (Use wildcards):


Restrict all users to specific IP addresses and address ranges:


Disallow all users except those named after specific IP addresses:


Restrict a specific user to a specific IP address, while still allowing all other users to log in without restrictions:


Note : In the OpenSSH configuration file, all configurations contained within the block Matchwill only apply to connections that match the criteria, regardless of indentation or carriage return. This means you have to be careful and ensure that configurations set to apply globally don't accidentally get placed in blocks Match. Always place all blocks Matchat the end of the configuration file to avoid discrepancies while applying configuration criteria.
After completing the configuration, add this criteria to the bottom of your OpenSSH server configuration file:


Then save and close the file with Ctrl + X, Ythen Enter. And check the syntax of the configuration file with the command:


If no errors appear, you can restart OpenSSH to apply your changed configuration above with the command:


So in this step, you have finished setting up an IP address whitelist on your OpenSSH server. Next, you will restrict a user's shell to limit the commands they are allowed to use.

Step 3 – Limit user shell interactions​

In addition to providing remote shell access, SSH is also great for transferring files and other data, for example via SFTP (Secure File Transfer Protocol). However, you don't always want to give users full shell access when they just need to perform file transfers.

In OpenSSH server there are many ways for you to configure to restrict the shell environment of specific users. For example, in this tutorial, you will configure to create users that can only use SFTP.

First, you can use commands /usr/sbin/nologinto disable interactions for specific user accounts.

To create a new user with nologinthe shell, use the following command:


You can rename alex to the username you want to create. In addition, you can also change the shell of an existing user to nologin, for example, if the sammy account already exists, use the command:


Now, these accounts will no longer be allowed to log in to the shell, but transferring files or data to these accounts will still work normally. You can try to test it by logging into the accounts that have been converted to nologintest:


Next, you should combine the use of nologinthe shell and configure some additional options to restrict the user accounts involved.

Proceed to open the OpenSSH configuration file with nanoor text editor of your choice:


Here, there are 2 configuration options that you can add to the configuration: ForceCommand internal-sftpand ChrootDirectory.

The option ForceCommandwill force the user to execute a specific command upon login. In this case, the command ForceCommandwill execute the command internal-sftp. In this case, the system will launch the SFTP daemon on-premises without needing additional support files or configuration. The purpose is to force users to log in using the SFTP protocol and to create SFTP accounts that can only share files.

And the option ChrootDirectoryis used to limit the file space for a particular user. When used in conjunction with ForceCommand internal-sftp, this will restrict users from being able to access only the folder you specify and prevent them from accessing other folders on the system.

Once you understand these two options, add the users you want to restrict to the configuration file as below:


Here, the account I limit is Alex, which comes with a limited space that only allows access inside /home/alex/and not elsewhere.

Note: Like I mentioned in step 2, you must be careful and ensure that globally set configurations are not accidentally placed in blocks Match. To avoid errors, blocks Matchshould be placed at the end of the configuration file. image.
After configuration is complete, save the file and check with the command:


If no errors appear, then your configuration file is stable, now restart the SSH service to apply these configurations:


So through step 3, you have set up very restrictive configurations for the alex user account . Specifically disable login and all SFTP activities are limited to that user's home directory. This will help ensure that this account will not be able to access other files on the system.

Step 4 – Some advanced security measures​

In this final step, you will implement various advanced security measures to ensure secure access to your SSH.

OpenSSH server can impose restrictions on a per-key basis. Specifically, these restrictions can be applied to any public key contained in the .ssh/authorized_keys. This capability is especially useful for access control. Additionally, it also allows users without sudo permissions to manage restrictions for their accounts.

Note: This security configuration can only be deployed when applying the SSH public key. For other authentication methods such as password or CA level, this option is disabled.
To proceed with imposing restrictions on the key, open the file .ssh/authorized_keysin nanoor your editor:


Another thing to note is that this configuration is applied on a per-key basis. Therefore, users will have to edit each key of each authorize_keys file one by one and do it for all users on the system. This process will be simple if the number of users is very small, however this is not a good idea for large scale with many users, high system complexity.

After opening the file authorized_keys, you will see that each line contains an SSH public key, which may begin with ssh-rsa AAAB …The configuration options you want to add can only be added to the beginning of that key's line, and they will also apply individually. for that key only.

Here are some configuration options that you can refer to:

• no-agent-forwarding: Disable SSH agent forwarding.
• no-port-forwarding: Disable SSH port forwarding.
• no-pty: Disable the ability to allocate tty (Is it a shell or terminal). Meaning the user will not be able to start the shell via an SSH connection.
• no-user-rc: Prevent execution of file ~/.ssh/rc.
• no-X11-forwarding: Disable X11 forwarding (Introduced in step 1).

Based on these options, you can add them to the keys you want to restrict, for example to disable X11 forwarding, or SSH agent, you add to the beginning of that key as follows:


Here ssh-rsa AAAB ...is the key in your system, and the options are added to the beginning of that key. Note that these options only apply to the key you add, to apply to another key, you must also these options must be added to the beginning of that key.

By default, this configuration has the mechanism "allow by default" and "block by exception", of course the reverse can be configured to improve safety.

The second way is to use the option restrict, which will implicitly deny all SSH features for the specific key. You can re-enable the feature using the configuration options outlined above, but without the no-.

For example, to disable all SSH features for a specific key except X11-forwarding, you can use the following configuration:


Here it means that you have turned off everything and only left X11-forwardingthis key. Normally you should use this method to limit locks. You can also add options commandto the key, this is quite similar to ForceCommandstep 3.

For example, to force users to authenticate using a specific key to perform once commandlogged in, you can add the following configuration:


However, the configuration option commandonly acts as an additional defense method and it should not be relied upon solely to limit SSH user activities, as there may be ways to bypass it.

So the best way is to use both methods, one restrictand then use it commandto make a second defensive wall like below:


The option restrictdisables all interactions, and the option command = "false"acts as a second command line guard in case the option ForceCommandor nologinshell fails.

After completing the configuration, save it and this key configuration file will automatically take effect immediately without having to reload the SSH service. So make sure to check the commands you used before disconnecting from the current SSH login session.

.thank you