we receive a weekly security report for our websites. It said our SSH version was outdated (we have OpenSSH_6.7p1, they recommend 7.5 or later).

Since there is no stable version for our distribution yet, we thought we'd just close port 22 on all internet facing machines (good practice anyways isn't it?).

Today came the new report. It still states 10 issues regarding the SSH version.

So my questions are:

  1. How can they find out the SSH version if the port is closed?
  2. wouldn't closing the port successfully mitigate all SSH security issues, no matter the version?
  • What OS/distribution are you running, and you up to date with their security updates? – marcelm Sep 11 '17 at 14:12

“SSH version is outdated” is not necessarily a security problem. Their recommendation is to install the latest version, but there is no benefit in running the latest version unless you want the latest features. For security, what matters is that you have all the security fixes applied. Many distributions apply security fixes to the version they ship. For example, CentOS 6 still ships OpenSSH 5.3p1 and will be receiving security updates until 2020; CentOS 7, the current release, ships OpenSSH 6.6.1p1. Debian jessie ships OpenSSH 6.7p1 and will also be receiving security updates until 2020, while the latest release stretch ships OpenSSH7.4p1.

In general, you should not install packages outside your distribution for critical infrastructure components such as OpenSSH. If you do, make sure to subscribe to security bulletins and apply security updates as soon as possible. If you just install OpenSSH 7.5 now and forget about it later, you're significantly weakening your security.

If you get a report that only says “version is outdated” and doesn't even try to determine whether the proper security patches have been applied, it's a bad report.

Closing external SSH access on servers that don't need them is a good idea regardless. One machine where the security updates are falling behind, or one machine where a user's password or key have been compromised, could get the attacker into your network. It's often a good idea to limit external access to a single gateway machine (or a small set of machines for redundancy) where updates and account are more closely monitored. Closing the port in the firewall will mitigate the issue of direct access. Indirect access (where the attacker gets into the network on a machine that's doing nothing important, and uses that as a relay to get into more important machine) will still be a concern.

You can check SSH access by yourself by running ssh -v MACHINENAME from outside. If MACHINENAME is running an SSH server and the firewall doesn't block you, you'll see a line like

debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Debian-5+deb8u3

That, as I write, is the current version on Debian jessie and is perfectly fine.

| improve this answer | |
  • thanks a lot for your detailed answer!! +1 They do in fact state why the version should be updated. They list 10 issues with version <7.5 (the last being: Untrusted search path vulnerability in ssh-agent.c in ssh-agent in OpenSSH allows remote attackers to execute arbitrary local PKCS#11 modules by leveraging control over a forwarded agent-socket. for OpenSSH <7.4) – Michael Niemand Sep 11 '17 at 12:14
  • 3
    @MichaelNiemand As Gilles said: distributors patch their version of OpenSSH to fix these problems, so the issues mentioned by your security report may very well be false. In general, judging security based on just the base version of software is useless. – marcelm Sep 11 '17 at 14:15
  • 1
    @MichaelNiemand As for that particular vulnerability, it is an OpenSSH client vulnerability, not affecting the OpenSSH server. Upgrading or disabling the server will not mitigate that vulnerability. That particular vulnerability also is unfixed in Debian Jessie (which you appear to be running). – marcelm Sep 11 '17 at 14:27
  • 1
    @marcelm I must have switched between “should not” and “should avoid” mid-writing. Thanks, fixed. – Gilles 'SO- stop being evil' Sep 11 '17 at 14:40
  • @MichaelNiemand It still sounds like the author of the security report is just copying from the release notes. There's no added value in that. Added value would be to identify which vulnerabilities are relevant to you. For example the one you cited only affects a fairly rare usage combination — forwarded agent socket without a shell account. – Gilles 'SO- stop being evil' Sep 11 '17 at 14:42

You can try to run nmap -sV IP -p 22 to check if the port is still open. Maybe it's an issue in the reporting? They keep reporting the version until they can validate that it has changed?

Closing the port will indeed mitigate issues in SSH. If SSH is still available on the internal network this might still be an issue if you can't trust the internal network. Should SSH be available on the machine? If not, disable it. If it should be available you should put this in a separate VLAN for administration.

| improve this answer | |
  • thanks for the nmap command. I always checked with telnet <ip> 22 - would this be effectively the same? – Michael Niemand Sep 11 '17 at 8:57
  • Telnet is another protocol. I believe telnet will give an error. Also, nmap -sV will uncover the version if it is leaked by the SSH server. – Silver Sep 11 '17 at 9:03
  • 1
    sorry, not trying to be a smart ass, but so does telnet: root@host:/home# telnet 22 Trying Connected to Escape character is '^]'. SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3 – Michael Niemand Sep 11 '17 at 9:16
  • 1
    Alright, my mistake. Telnet must be imposing very little limitation on the protocol and present the response from the SSH server to the user. Is this same command possible on the public IP? If so, the issue might have been reported correctly. – Silver Sep 11 '17 at 9:28
  • 8
    @Silver The telnet application typically only uses the Telnet protocol when connecting on the Telnet port (23/tcp). In other cases, it acts as a raw TCP client. – user Sep 11 '17 at 11:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.