Insecure configuration for OpenSSH found

[fshmcallister]

We found insecure configuration issues with OpenSSH on {devices}. To improve the security posture of your node, please consider making the following changes: {changes}

part of #198

[Menmarin]

Title

Insecure OpenSSH config detected

TL:DR

We have detected security issues in the configuration of OpenSSH on [DEVICES]. Please consider making the recommended changes to the config file to improve the security posture of your node.

FAQ Version

As you probably know the SSH (Secure Shell) is a method to remote login to a server. SSH is usually secure, however if used with the default settings, can be vulnerable to attacks from unwanted parties.

By default, the SSH config file is set up so that everything is basic and easy to follow. Whilst this is a great way for new developers to get used to setting up SSH servers, it paves the way for vulnerabilities to be exploited. Simple vulnerabilities such as plain text passwords and giving users more access than they need. For more information on how to secure your OpenSSH configuration, please follow this step-by-step guide.

[Menmarin]

I feel like I can add more the the FAQ but the article I wrote covers all that, so should I just take some from the article and put it in the FAQ or is linking the article enough?

[vpetersson]

@fshmcallister / @Menmarin - this one needs a bit rework as we've gone ahead and refactored this in the back-end to make it fit the workflow. We need to break the recommended actions for OpenSSh into three different messages:

• PermitRootLogin
• PasswordAuthentication
• AllowAgentForwarding

Each need its own version.

[fshmcallister]

Title Root login enabled for OpenSSH

TL;DR It appears that you have root login enabled in your OpenSSH config which increases the probability of a the node being compromised from a brute-force attack (in particular if you have not disabled password authentication).

FAQ SSH (Secure Shell) is a method to remote login to a server. SSH is usually secure, however if used with the default settings, can be vulnerable to attacks from unwanted parties. By default, the SSH config file is preset with some values allowing for new developers to get used to setting up SSH servers. However, this often exposes vulnerabilities by not being restrictive enough.

We've detected that `PermitRootLogin` is enabled. A common attack is brute forcing the login of superuser and thereby compromising the entire machine rather than on a user-by-user basis. First, ensure you are able to use an SSH login on a non-root user. Once you have confirmed this, disable the root login by changing the `/etc/ssh/sshd_config` file to have the following line:

``` PermitRootLogin no ```

Once you've updated the configuration, make sure to restart the SSH server using `sudo service ssh restart`.

For more information on how to secure OpenSSH, see our larger tutorial [here](https://wott.io/blog/tutorials/2019/10/25/audit-openssh-security).

Code Snippet

Ignore for now.

[fshmcallister]

Title Password authentication enabled for OpenSSH

TL;DR It appears that you have password authentication enabled in your OpenSSH config which may leave your entire machine vulnerable to brute-force attacks.

FAQ SSH (Secure Shell) is a method to remote login to a server. SSH is usually secure, however if used with the default settings, can be vulnerable to attacks from unwanted parties. By default, the SSH config file is preset with some values allowing for new developers to get used to setting up SSH servers. However, this often exposes vulnerabilities by not being restrictive enough.

We've detected that `PasswordAuthentication` is enabled. Passwords can easily be exploited and brute-forced due to human error and is less secure than identifying using SSH keys.

Where possible, it is ideal to completely remove the need for passwords to improve your security posture.

**Warning:** Before you disable password authentication, make sure that you have [generated and installed](https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys-on-ubuntu-1604) your SSH keys on the remote server. Failure to do so will result in that you will be locked out of your server.

Edit the `/etc/ssh/sshd_config` file like so:

``` PasswordAuthentication no ```

Once you've updated the configuration, make sure to restart the SSH server using `sudo service ssh restart`.

For more information on how to secure OpenSSH, see our larger tutorial here

Code Block

[fshmcallister]

Title Agent forwarding enabled for OpenSSH

TL;DR It appears that you have Agent forwarding enabled in your OpenSSH config. If enabled, an attacker who have already compromised the server could use this to steal your SSH keys.

FAQ SSH (Secure Shell) is a method to remote login to a server. SSH is usually secure, however if used with the default settings, can be vulnerable to attacks from unwanted parties. By default, the SSH config file is preset with some values allowing for new developers to get used to setting up SSH servers. However, this often exposes vulnerabilities by not being restrictive enough.

We've detected that `AllowAgentForwarding` is enabled. This means that you can SSH into one host and from there to a different host using the SSH key on your local machine. This might be the case if you cannot directly access the final host (for instance if you're using a [Bastion host](https://en.wikipedia.org/wiki/Bastion_host)). However, doing so leaves a socket open on the server, which then can be attacked.

Unless you need this feature, we recommend you disable this feature by edit the `/etc/ssh/sshd_config` file like so:

``` AllowAgentForwarding no ```

For more information on how to secure OpenSSH, see our larger tutorial [here](https://wott.io/blog/tutorials/2019/10/25/audit-openssh-security)

Code Block

Not applicable.

[a-martynovich]

@fshmcallister @vpetersson This list is missing PermitEmptyPasswords and Protocol.

[vpetersson]

@fshmcallister Could you tackle that too? Thanks.

[fshmcallister]

Will need to be done this evening if that’s okay

[fshmcallister]

Title Empty passwords enabled for OpenSSH

TL;DR It appears that you have empty passwords enabled in your OpenSSH config. If enabled, an attacker may be able to access your system without a password.

FAQ SSH (Secure Shell) is a method to remote login to a server. SSH is usually secure, however if used with the default settings, can be vulnerable to attacks from unwanted parties. By default, the SSH config file is preset with some values allowing for new developers to get used to setting up SSH servers. However, this often exposes vulnerabilities by not being restrictive enough.

We've detected that `PermitEmptyPasswords` is enabled. This means a user can make changes or access your information without needing a password to authenticate, as the password field is optional (can be empty). This is particularly dangerous for example if the root user has an empty password. This is not recommended in any instance, particularly over the internet.

To disable this, access and change the `/etc/ssh/sshd_config` file like so:

``` PermitEmptyPasswords no ```

For more information on how to secure OpenSSH, see our larger tutorial [here](https://wott.io/blog/tutorials/2019/10/25/audit-openssh-security)

Code Block

Not applicable.

[fshmcallister]

Title Insecure protocol option enabled for OpenSSH

TL;DR It appears that you have enabled protocol 1 for OpenSSH. This protocol is outdated and insecure, consider exclusively using protocol 2.

FAQ SSH (Secure Shell) is a method to remote login to a server. SSH is usually secure, however if used with the default settings, can be vulnerable to attacks from unwanted parties. By default, the SSH config file is preset with some values allowing for new developers to get used to setting up SSH servers. However, this often exposes vulnerabilities by not being restrictive enough.

We've detected that the option to use protocol 1 in `Protocol` is enabled. Protocol 1 is insecure compared to protocol 2 as it is vulnerable to insertion attacks and is weak cryptographically. By default OpenSSH will opt to use protocol 2 and in failing that, protocol 1. However, the option to use protocol 1 at all is still unsafe. We suggest that you remove the secondary preference for protocol 1 and disable it as an option at all.

To do so, access and change the `/etc/ssh/sshd_config` file like so:

``` Protocol 2 ```

For more information on how to secure OpenSSH, see our larger tutorial [here](https://wott.io/blog/tutorials/2019/10/25/audit-openssh-security)

Code Block

Not applicable.