Call Us! 1-800-383-5193
Call Us! 1-800-383-5193
Call Us! 1-800-383-5193

Need Help?

Emergency Response Time custom

Our experts have had an average response time of 12.45 minutes in December 2020 to fix urgent issues.

We will keep your servers stable, secure and fast at all times for one fixed price.

Harden OpenSSH Client on Ubuntu 18.04 – Do it with ease

by | Jan 7, 2021

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.

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.

Tunnel no

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:

ForwardAgent no

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.

# SendEnv

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:

StrictHostKeyChecking ask

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:

Ciphers -arcfour*,-*cbc

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 !,!,!server1.your-domain,!,*
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.




Never again lose customers to poor server speed! Let us help you.

Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.


var google_conversion_label = "owonCMyG5nEQ0aD71QM";


Submit a Comment

Your email address will not be published. Required fields are marked *

Privacy Preference Center


Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.

PHPSESSID - Preserves user session state across page requests.

gdpr[consent_types] - Used to store user consents.

gdpr[allowed_cookies] - Used to store user allowed cookies.

PHPSESSID, gdpr[consent_types], gdpr[allowed_cookies]


Statistic cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.

_ga - Preserves user session state across page requests.

_gat - Used by Google Analytics to throttle request rate

_gid - Registers a unique ID that is used to generate statistical data on how you use the website.

smartlookCookie - Used to collect user device and location information of the site visitors to improve the websites User Experience.

_ga, _gat, _gid
_ga, _gat, _gid


Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.

IDE - Used by Google DoubleClick to register and report the website user's actions after viewing or clicking one of the advertiser's ads with the purpose of measuring the efficacy of an ad and to present targeted ads to the user.

test_cookie - Used to check if the user's browser supports cookies.

1P_JAR - Google cookie. These cookies are used to collect website statistics and track conversion rates.

NID - Registers a unique ID that identifies a returning user's device. The ID is used for serving ads that are most relevant to the user.

DV - Google ad personalisation

IDE, test_cookie, 1P_JAR, NID, DV, NID
IDE, test_cookie


These are essential site cookies, used by the google reCAPTCHA. These cookies use an unique identifier to verify if a visitor is human or a bot.