Need to Harden OpenSSH Client on Ubuntu 18.04?
At Bobcares, we often do this hardening for our customers as a part of our Server Management Services.
Today let’s see how our Expert Support Techs get this done for our customers.
Why Harden OpenSSH Client?
OpenSSH client is used for SSH from the client’s end.
It is important to harden the OpenSSH Client for the following reasons:
1. For avoiding attacks on the network.
2. To prevent client from getting overloaded by malicious servers sending any unnecessary data packets, nefarious control sequences, or large amounts of irrelevant data.
3. Also for avoiding human errors such as wrong giving a wrong address or making changes in the configuration values unwantedly.
Steps for Hardening OpenSSH Client on Ubuntu 18.04
We will check the steps that our Support Techs follow to harden OpenSSH Client on Ubuntu 18.04.
We need to log in to the SSH client device as a non-root user first.
The steps to follow are given below:
1. General Hardening
First, we can do some initial hardening configurations in order to improve the overall security of your SSH client.
Here we will make changes in the global OpenSSH client configuration file /etc/ssh/ssh_config.
$ sudo cp /etc/ssh/ssh_config /etc/ssh/ssh_config.bak
We can use any text editor to open the file.
$ sudo nano /etc/ssh/ssh_config
And make the following changes in the configuration.
ForwardX11 no ForwardX11Trusted no
Next, we can disable SSH tunneling this is only done if SSH tunneling is not in use by the server.
We can also consider disabling SSH agent forwarding if it is not necessary, prevent servers from requesting to use the local SSH agent to authenticate onward SSH connections:
Usually, SSH client is setup to use password authentication or public-key authentication when connecting to servers.
However, OpenSSH client supports some other authentication methods which will be present by default. If these are not necessary, we can disablethem to reduce the potential attacks.
GSSAPIAuthentication no HostbasedAuthentication no
OpenSSH client allows you to automatically pass custom environment variables when connecting to servers. If this is not required in our setup, we can prevent any variables from being sent.
This can be done by ensuring that the SendEnv option is commented out.
Finally, we must ensure that strict host key checking is enabled so that we get proper warnings when the host key/fingerprint of a remote server changes, or when connecting to a new server for the first time:
Save and exit the file.
After making changes in the configuration file we need to validate the syntax of the new configuration by running SSH in test mode.
$ ssh -G .
We can substitute the ‘ . ‘ with any hostname to test/simulate any settings that are within Match or Host blocks.
If the configuration file has valid syntax, the options that will apply to that specific connection can be seen.
2. Restricting Available Ciphers
Next, we will configure the cipher suites available within the SSH client.
For this, we can open the file /etc/ssh/ssh_config in any text editor.
$ sudo nano /etc/ssh/ssh_config
Then, add the following line to the top of the file:
This will disable the legacy Arcfour ciphers, as well as all ciphers using Cipher Block Chaining (CBC).
Finally, we can wish to test your SSH client configuration again to check for any potential errors:
$ ssh -G .
[Facing difficulty to restrict? We are happy to help you!]
3.Securing Configuration File and Private Key Permissions
This is helpful in preventing accidental or malicious changes, or private key disclosure to SSH client configuration files
Generally, on Ubuntu, the OpenSSH client configuration files are set up such that each user can only edit their own local configuration file (~/.ssh/config).
We need sudo or administrative access for editing the system-wide configuration /etc/ssh/ssh_config.
First, check the current permissions of /etc/ssh/ssh_config
$ stat -c "%a %A %U:%G" /etc/ssh/ssh_config
The %A %a %U:%G option will print the permissions along with the user/group that owns the file.
This will output will be as given below:
644 -rw-r--r-- root:root
In the above result, the permissions are correct, the root owns the file entirely, and only the root user has permission to write to/modify it.
However, if the own output is different, we must reset the permissions back to the default by using the following commands:
$ sudo chown root:root /etc/ssh/ssh_config $ sudo chmod 644 /etc/ssh/ssh_config
Next, we can carry out the same checks for your own local SSH client configuration file, if you have one:
$ stat -c "%a %A %U:%G" ~/.ssh/config
We will get an output similar to the following:
644 -rw--r--r-- user:user
We should reset the permissions if we find it to be different them using the following commands:
$ chown user:user ~/.ssh/config $ chmod 644 ~/.ssh/config
Next, we can check the permissions for each of the SSH private keys that we have within our ~/.ssh directory.
For printing the current permission and ownership values for each private key we can use the following command:
$ stat -c "%a %A %U:%G" ~/.ssh/id_rsa
The output will be similar to the one given below:
600 -rw------- user:user
If the permissions are not set properly, we can use the following commands on each private key file to reset them to the secure defaults:
$ chown user:user ~/.ssh/id_rsa $ chmod 600 ~/.ssh/id_rsa
4. Restricting Outgoing Connections Using a Host Allowlist
As a final step of hardening, we will set up an outgoing allowlist in order to restrict the hosts that the SSH client is able to connect to.
We can apply this either at the system-level (/etc/ssh/ssh_config) or using your local user configuration file (~/.ssh/config).
Here, we will use the local user configuration file.
First, open the file, or create it if it does not already exist:
$ nano ~/.ssh/config
And then add the following content, substituting our IP in the allow list of IP addresses and hostnames:
Match host !203.0.113.1,!192.0.2.1,!server1.your-domain,!github.com,* Hostname localhost
Save and close the file after making the changes.
[Need assistance for hardening? We are happy to help you!]
To conclude, we saw how our Support Engineers harden OpenSSH Client with some quick and easy steps.