继新发现的 POODLE 漏洞，我想在我的所有 SSH 服务器上禁用 SSLv3。如何使用 OpenSSH 实现此目的？
答案1
对于 OpenSSH 来说这不是问题，因为它不使用 SSL。
摘录-SSL 与 SSH 有什么区别？哪个更安全？他们对隧道周围的事物有不同的看法。 SSL 传统上使用 X.509 证书来公布服务器和客户端公钥； SSH 有自己的格式。此外，SSH 附带了一组用于隧道内部传输的协议（多路复用多个传输、在隧道内执行基于密码的身份验证、终端管理...），而 SSL 中没有这样的协议，或者更准确地说，当这些东西在 SSL 中使用，它们不被认为是 SSL 的一部分（例如，当在 SSL 隧道中进行基于密码的 HTTP 身份验证时，我们说它是“HTTPS”的一部分，但它实际上以类似的方式工作SSH 会发生什么）。
从概念上讲，您可以采用 SSH 并将隧道部分替换为 SSL 中的隧道部分。您还可以采用 HTTPS 并将 SSL 替换为 SSH-with-data-transport 以及一个从其证书中提取服务器公钥的钩子。科学上不存在不可能，如果处理得当，安全性将保持不变。然而，目前还没有一套广泛的约定或现有工具。
作为进一步的证据，我会引导你RFC 4253，其中讨论了“安全外壳 (SSH) 传输层协议”。这是 SSH 自己的自定义传输层，它与 HTTPS/SSL 使用的传输层不同。
本文档描述了 SSH 传输层协议，该协议通常运行在 TCP/IP 之上。该协议可用作许多安全网络服务的基础。它提供强大的加密、服务器身份验证和完整性保护。它还可以提供压缩。
最后，来自安全 SE 网站的问答题为：SSL3“贵宾犬”漏洞关于 POODLE 攻击有这样的说法。
摘抄Poodle 攻击在选择的明文上下文中起作用，就像之前的 BEAST 和 CRIME 一样。攻击者对受 SSL 保护的数据感兴趣，他可以：
- 在自己想要获取的秘密值前后注入自己的数据；
- 检查、拦截并修改线路上产生的字节。
满足此类条件的主要也是唯一可能的场景是 Web 上下文：攻击者运行一个虚假的 WiFi 接入点，并注入一些自己的 Javascript 作为受害者浏览的网页（HTTP，而不是 HTTPS）的一部分。邪恶的 Javascript 使浏览器向 HTTPS 站点（例如银行网站）发送请求，受害者的浏览器拥有该站点的 cookie。攻击者想要那个 cookie。
因此，OpenSSH 无需针对此特定威胁采取任何操作。