How to remediate – SSH Protocol Versions Supported

1. Introduction

The SSH Protocol Versions Supported vulnerability means an SSH server is running on a system, potentially allowing older, less secure versions of the protocol to be used. This matters because older protocols have known weaknesses that attackers can exploit. Systems commonly affected include Linux servers, network devices and virtual machines with SSH enabled. A successful attack could compromise confidentiality, integrity, and availability of the host.

2. Technical Explanation

This vulnerability indicates the presence of an SSH server supporting multiple protocol versions. While not inherently a flaw, it increases the attack surface as older protocols may contain known vulnerabilities. An attacker could attempt to negotiate a connection using a weaker protocol version if the server allows it. There is no specific CVE associated with simply *supporting* multiple versions; however, weaknesses exist in older SSH protocols like SSH-1 and early versions of SSH-2.

• Root cause: The SSH daemon is configured to accept connections using multiple SSH protocol versions.
• Exploit mechanism: An attacker attempts to connect to the server specifying an older, vulnerable protocol version. If accepted, they can then attempt to exploit known weaknesses in that protocol. For example, a downgrade attack could force use of SSH-1 which has several documented vulnerabilities.
• Scope: Linux servers (OpenSSH), network devices with embedded SSH daemons, virtual machines running SSH services. Affected versions depend on the specific SSH implementation and its configuration.

3. Detection and Assessment

• Quick checks: Use the following command to list supported cipher suites and protocols. This indicates what versions are accepted.
• Scanning: Nessus plugin ID 35680 can identify SSH protocol versions. OpenVAS also has relevant scans, but results may vary. These are examples only.
• Logs and evidence: Check SSH server logs (typically /var/log/auth.log or /var/log/secure) for connection attempts specifying older protocols. Look for messages indicating successful protocol negotiation with older versions.

ssh -V

4. Solution / Remediation Steps

The following steps detail how to fix the issue by disabling support for insecure SSH protocol versions.

4.1 Preparation

• Ensure you have console access as a fallback in case of connection issues. Roll back plan: restore from backup/snapshot or revert configuration changes.
• A change window may be needed for production systems; approval from system owners is recommended.

4.2 Implementation

1. Step 1: Edit the SSH daemon configuration file (typically /etc/ssh/sshd_config).
2. Step 2: Add or modify the `Protocol` directive to only allow Protocol 2.
3. Step 3: Save the changes to sshd_config.
4. Step 4: Restart the SSH service to apply the new configuration.

4.3 Config or Code Example

Before

# Protocol 2,1  (Allowing both versions)

After

Protocol 2 (Only allowing version 2)

4.4 Security Practices Relevant to This Vulnerability

Several security practices directly address this vulnerability type.

• Practice 1: Least privilege – limit SSH access to only authorized users and systems, reducing the impact if exploited.
• Practice 2: Secure defaults – configure SSH with strong ciphers and disable weak protocols by default.

4.5 Automation (Optional)

The following Ansible snippet can be used to enforce Protocol 2 on multiple systems.

---
- hosts: all
  tasks:
    - name: Ensure SSH protocol is set to 2
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^Protocol'
        line: Protocol 2
      notify: Restart sshd
  handlers:
    - name: Restart sshd
      service:
        name: sshd
        state: restarted

5. Verification / Validation

Confirm the fix worked by checking that only SSH protocol version 2 is supported and performing a basic service smoke test.

• Post-fix check: Run `ssh -V` again; the output should show only Protocol 2.
• Re-test: Re-run the Nessus or OpenVAS scan to confirm that older protocols are no longer detected.
• Smoke test: Attempt to connect to the server using a standard SSH client with Protocol 2 enabled. Ensure you can still log in successfully.
• Monitoring: Monitor SSH logs for failed connection attempts specifying unsupported protocol versions.

ssh -V (Expected output: OpenSSH_8.x, Protocol 2.0)

6. Preventive Measures and Monitoring

Update security baselines and implement checks in CI/CD pipelines to prevent this issue.

• Baselines: Update your security baseline or policy (for example, CIS control 3.1) to require Protocol 2 only for SSH.
• Pipelines: Add a check in your CI or deployment pipeline to scan for insecure SSH configurations using tools like `ssh-audit`.
• Asset and patch process: Review SSH configuration changes regularly as part of your asset management and patch process. A quarterly review is sensible.

7. Risks, Side Effects, and Roll Back

Disabling older protocols may cause compatibility issues with very old clients. The roll back steps are straightforward.

• Risk or side effect 1: Older SSH clients that only support Protocol 1 will no longer be able to connect. Mitigation: upgrade those clients if possible, or provide a temporary workaround (not recommended).
• Risk or side effect 2: Incorrect configuration could lock you out of the server. Mitigation: test changes thoroughly in a non-production environment first.
• Roll back: Step 1: Edit /etc/ssh/sshd_config and remove or comment out the `Protocol` directive. Step 2: Save the changes. Step 3: Restart the SSH service.

8. References and Resources

Links to official advisories and trusted documentation.

• Vendor advisory or bulletin: OpenSSH Website
• NVD or CVE entry: No specific CVE for supporting multiple protocols, but see related vulnerabilities in older SSH versions on the NVD website (https://nvd.nist.gov/).
• Product or platform documentation relevant to the fix: OpenSSH Configuration Documentation