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?
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.excerpt
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.
So there is no action that needs to be taken for OpenSSH against this particular threat.
- How POODLE Happened
- Taxonomy of Ciphers/MACs/Kex available in SSH?
- Secure Configuration of Ciphers/MACs/Kex available in SSH