In wake of the newly-discovered POODLE vulnerability, I'd like to disable SSLv3 on all of my SSH servers. How do I achieve this with OpenSSH?

  • Is not even affected, check CVE­-2014­-3566
    – Braiam
    Commented Oct 15, 2014 at 1:51
  • @Braiam, I was prompted to ask this question because the article linked advises users to secure their SSH servers against this vulnerability.
    – drs
    Commented Oct 15, 2014 at 2:21
  • It was their mistake. Google, the one that discovered it didn't said anything about SSH.
    – Braiam
    Commented Oct 15, 2014 at 2:23
  • 1
    -1 because SSH and SSL/TLS are two completely different protocols. ZDnet is not a reliable technical source.
    – bortzmeyer
    Commented Oct 15, 2014 at 13:50
  • 2
    @bortzmeyer while technically you are right, the question is actually not that bad. And a lots of people are probably asking the same.
    – peterph
    Commented Oct 17, 2014 at 13:14

1 Answer 1


This is not an issue for OpenSSH since it doesn't make use of SSL.

excerpt - What is the difference between SSL vs SSH? Which is more secure?

They differ on the things which are around the tunnel. SSL traditionally uses X.509 certificates for announcing server and client public keys; SSH has its own format. Also, SSH comes with a set of protocols for what goes inside the tunnel (multiplexing several transfers, performing password-based authentication within the tunnel, terminal management...) while there is no such thing in SSL, or, more accurately, when such things are used in SSL they are not considered to be part of SSL (for instance, when doing password-based HTTP authentication in a SSL tunnel, we say that it is part of "HTTPS", but it really works in a way similar to what happens with SSH).

Conceptually, you could take SSH and replace the tunnel part with the one from SSL. You could also take HTTPS and replace the SSL thing with SSH-with-data-transport and a hook to extract the server public key from its certificate. There is no scientific impossibility and, if done properly, security would remain the same. However, there is no widespread set of conventions or existing tools for that.

As further evidence I'd direct you to RFC 4253, which discusses the "The Secure Shell (SSH) Transport Layer Protocol". This is SSH's own custom transport layer, it does not use the same one that HTTPS/SSL uses.

This document describes the SSH transport layer protocol, which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression.

Lastly this Q&A from the security SE site titled: SSL3 “Poodle” Vulnerability had this to say about the POODLE attack.


The Poodle attack works in a chosen-plaintext context, like BEAST and CRIME before it. The attacker is interested in data that gets protected with SSL, and he can:

  • inject data of his own before and after the secret value that he wants to obtain;
  • inspect, intercept and modify the resulting bytes on the wire.

The main and about only plausible scenario where such conditions are met is a Web context: the attacker runs a fake WiFi access point, and injects some Javascript of his own as part of a Web page (HTTP, not HTTPS) that the victim browses. The evil Javascript makes the browser send requests to a HTTPS site (say, a bank Web site) for which the victim's browser has a cookie. The attacker wants that cookie.

So there is no action that needs to be taken for OpenSSH against this particular threat.


More reading

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .