OpenSSH7.0兼容性测试报告

时间 2019-11-12

标签 openssh7.0 openssh 兼容性测试报告繁體版

原文原文链接

背景

2015年下，某省运营商综合网络管理系统。css

按照安全管理要求，需对全系统主机的OpenSSH版本升级。html

第一次测试：系统自有服务器

主机：RedHat Linux ／SunOS：系统内所有主机升级，内部互通没有问题git

第二次测试：主机到网络设备SSH互通性

国外厂商

思科（系统版本IOS 12.0系列，IOS 4.0系列），RedBack（系统版本SEOS-12系列，SEOS-6.0系列）github

目前仅支持diffie-hellman-group1-sha一、ssh-dss两种算法。算法

固然不排除今年国产化运动影响，国外厂商维保过时等缘由致使的售后升级服务滞后。promise

国内厂商

华为，不管是城域骨干网设备，仍是IPRAN 各型号，甚至老式交换机都彻底兼容。安全

中兴，只有较新的CTN9000-E V3.00.10系列能有限支持diffie-hellman-group1-sha1，服务器

其它各型号在服务器OpenSSH7.0以上版本后都没法正常访问。网络

缘由解析

‍

直接缘由：OpenSSH7.0安全特性升级

基于安全考虑，OpenSSH7.0将diffie-hellman-group1-sha1，ssh-dss等运行时状态默认变动为禁用。架构

* Support for the 1024-bit diffie-hellman-group1-sha1 key exchange

is disabled by default at run-time.

* Support for ssh-dss, ssh-dss-cert-* host and user keys is disabled

by default at run-time

采购缘由：国产化运动

国产化是近年以来的国家战略，各行各业都有涉及。在本次案例中，国际大厂Cicso,RedBack,Juniper等，我的觉得更大的可能不是没法更新，而是基于商务缘由。既然你不在维保合同期以内，又没有继续采购的计划，那我干吗还给你升级？

甚至由此能够推论：针对在网国外厂商设备，漏洞多又没有升级保障，会变成攻击和防御的重灾区。

软件缘由：硬件厂商系统架构水平差别

一样是国内厂家，测试对比结果却很是强烈！！这实际上是没有想到的。经过这个小细节，能够看出华为的系统架构与中兴早已拉开境界上的差距。结合近年来，华为出入开源社区的身影，更能够说明其对系统内核的理解和掌握已经到了至关的程度。

我的揣测，其早期版本可能也没有多好的支持。因为架构设计较好，又有更高的自我要求，逐步经过补丁升级，不动声色地就更新好了。

OpenSSH7.0之后的演进

针对密钥强度和加密算法方面更新会持续增强，必须有所准备

We plan on retiring more legacy cryptography in the next release including:

* Refusing all RSA keys smaller than 1024 bits (the current minimum is 768 bits)

* Several ciphers will be disabled by default: blowfish-cbc, cast128-cbc, all arcfour variants and the rijndael-cbc aliases for AES.

* MD5-based HMAC algorithms will be disabled by default.

‍延伸：Logjam Attack ‍

（本人没查到对应的中文名称，暂翻译为“僵尸攻击”，欢迎指正）

一种针对Diffie-Hellman密钥交换技术发起的攻击，而这项技术应用于诸多流行的加密协议，好比HTTPS、TLS、SMTPS、SSH及其余协议。一个国外计算机科学家团队2015-5-20公开发布。

延伸：开源组件演进追踪

本案例实际操做过程当中，开头走了不少弯路，并无一下找到要害。

根源在于团队缺少关注开源产品演进方向的意识和习惯，也缺少直接阅读、理解官方文档的习惯。

OpenSSH 7.0 变动说明

Changes since OpenSSH 6.9

=========================

This focus of this release is primarily to deprecate weak, legacy and/or unsafe cryptography.

Security --------

* sshd(8): OpenSSH 6.8 and 6.9 incorrectly set TTYs to be world-

   writable. Local attackers may be able to write arbitrary messages

   to logged-in users, including terminal escape sequences.

   Reported by Nikolay Edigaryev.

* sshd(8): Portable OpenSSH only: Fixed a privilege separation

   weakness related to PAM support. Attackers who could successfully

   compromise the pre-authentication process for remote code

   execution and who had valid credentials on the host could

   impersonate other users. Reported by Moritz Jodeit.

* sshd(8): Portable OpenSSH only: Fixed a use-after-free bug

   related to PAM support that was reachable by attackers who could

   compromise the pre-authentication process for remote code

   execution. Also reported by Moritz Jodeit.

* sshd(8): fix circumvention of MaxAuthTries using keyboard-

   interactive authentication. By specifying a long, repeating

   keyboard-interactive "devices" string, an attacker could request

   the same authentication method be tried thousands of times in

   a single pass. The LoginGraceTime timeout in sshd(8) and any

   authentication failure delays implemented by the authentication

   mechanism itself were still applied. Found by Kingcope.

Potentially-incompatible Changes

--------------------------------

* Support for the legacy SSH version 1 protocol is disabled by

   default at compile time.

* Support for the 1024-bit diffie-hellman-group1-sha1 key exchange

   is disabled by default at run-time. It may be re-enabled using

   the instructions at http://www.openssh.com/legacy.html

* Support for ssh-dss, ssh-dss-cert-* host and user keys is disabled

   by default at run-time. These may be re-enabled using the

   instructions at http://www.openssh.com/legacy.html

* Support for the legacy v00 cert format has been removed.

* The default for the sshd_config(5) PermitRootLogin option has

   changed from "yes" to "prohibit-password".

* PermitRootLogin=without-password/prohibit-password now bans all

   interactive authentication methods, allowing only public-key,

   hostbased and GSSAPI authentication (previously it permitted

   keyboard-interactive and password-less authentication if those

   were enabled).

‍解决方案（翻译）‍

OpenSSH实现了全部符合SSH标准的加密算法，使得应用之间能够互相兼容，可是自从一些老式的算法被发现不够强壮以来，并非全部的算法都会默认启用。

当OpenSSH拒绝链接一个只支持老式算法的应用时，咱们该如何作呢？

当一个SSH客户端与一个服务端创建链接的时候，两边会互相交换链接参数清单。清单包括用于加密链接的编码信息，消息认证码（MAC）用于防止网络嗅探篡改，

公钥算法可让服务端向客户端证实它是李刚（我就是我，而不是另外一个“我”），密钥交换算法是用来生成每次链接的密钥。在一次成功的链接中，这里的每一个参数必须有一组互相支持的选择。

当客户端和服务端通信的时候，不能匹配到一组互相支持的参数配置，那么这个链接将会失败。

OpenSSH(7.0及以上版本）将输出一个相似的错误信息：

Unable to negotiate with 127.0.0.1: no matching key exchange method found.

Their offer: diffie-hellman-group1-sha1

在这种状况下，客户端和服务端不可以就密钥交换算法达成一致。服务端只提供了一个单一的算法：diffie-hellman-group1-sha1。

OpenSSH能够支持这种算法，可是它默认不启用，由于这个算法很是弱，理论上存在僵尸攻击的风险。

这个问题的最好的解决方案是升级软件。

OpenSSH禁用的算法，都是那些咱们明确不推荐使用的，由于众所周知它们是不安全的。

在某些状况下，立科升级也许是不可能的，你可能须要临时地从新启用这个较弱的算法以保持访问。

在上面这种错误信息的状况下，OpenSSH能够配置启用diffie-hellman-group1-sha1 密钥交换算法（或者任何其它被默认禁用的），

可经过KexAlgorithm选项－或者在命令行：

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 user@127.0.0.1

或者在 ~/.ssh/config 配置文件中:

Host somehost.example.org

KexAlgorithms +diffie-hellman-group1-sha1

命令行中ssh和“＋”号之间链接算法选项的配置，对客户端默认设置来讲至关于替换。

经过附加信息，你能够自动升级到最佳支持算法，当服务端开始支持它的时候。

另外一个例子，主机验证过程当中，当客户端和服务端未能就公钥算法达成一致的时候：

Unable to negotiate with 127.0.0.1: no matching host key type found.

Their offer: ssh-dss

OpenSSH 7.0及以上版本一样禁用了ssh-css(DSA)公钥交换算法。

它也太弱了，咱们强烈不建议使用它。

ssh -oHostKeyAlgorithms=+ssh-dss user@127.0.0.1

或者在 ~/.ssh/config 配置文件中:

Host somehost.example.org

HostkeyAlgorithms ssh-dss

视服务端配置状况而定，验证过程当中其它链接参数也可能失败。

你启用它们的时候，也许须要肯定编码方式或者消息验证码配置选项。

延伸：查询 SSH 已支持的算法

ssh -Q cipher # 支持的编码方式

ssh -Q mac # 支持的消息验证码

ssh -Q key # 支持的公钥类型

ssh -Q kex # 支持的密钥交换算法

最后，当你须要试图链接一个特殊主机的时候，也能够经过－G选项查询实际使用ssh配置。

ssh -G user@somehost.example.com

将列出全部的配置选项，包括被选用的编码方式，消息验证码，公钥算法，密钥算法参数的值。

解决方案（原文）

Using OpenSSH with legacy SSH implementations

OpenSSH implements all of the cryptographic algorithms needed for compatibility with standards-compliant SSH implementations,

but since some of the older algorithms have been been found weak not all are algorithms are enabled by default.

This page describes what to do when OpenSSH refuses to connect with an implementation that only supports legacy algorithms.

When a SSH client connects to a server, each side offers lists of connection parameters to the other.

These include the ciphers to encrypt the connection, the message authentication codes (MACs) used to detect traffic modification,

the public key algorithms that the server can use to authenticate itself to the client and the key exchange methods that are used to generate per-connection keys.

In a successful connection, there is at least one mutually-supported choice for each parameter.

If the client and server are unable to agree on a mutual set of parameters then the connection will fail.

OpenSSH (7.0 and greater) will produce an error message like this:

Unable to negotiate with 127.0.0.1: no matching key exchange method found.

Their offer: diffie-hellman-group1-sha1

In this case, the client and server were unable to agree on the key exchange algorithm. The server offered only a single method diffie-hellman-group1-sha1. OpenSSH supports this method, but does not enable it by default because is weak and within theoretical range of the so-called Logjam attack.

The best resolution for these failures is to upgrade the software at the other end.

OpenSSH only disables algorithms that we actively recommend against using because they are known to be weak.

In some cases, this might not be immediately possible so you may need to temporarily re-enable the weak algorithms to retain access.

For the case of the above error message, OpenSSH can be configured to enable the diffie-hellman-group1-sha1 key exchange algorithm (or any other that is disabled by default) using the KexAlgorithm option - either on the command-line:

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 user@127.0.0.1

or in the ~/.ssh/config file:

Host somehost.example.org

KexAlgorithms +diffie-hellman-group1-sha1

The '+' before the list instructs ssh to append the algorithm to the client's default set rather than replacing the default.

By appending, you will automatically upgrade to the best supported algorithm when the server starts supporting it.

Another example, this time where the client and server fail to agree on a public key algorithm for host authentication:

Unable to negotiate with 127.0.0.1: no matching host key type found.

Their offer: ssh-dss

OpenSSH 7.0 and greater similarly disables the ssh-dss (DSA) public key algorithm.

It too is weak and we recommend against its use.

It can be re-enabled using the HostkeyAlgorithms configuration option:

ssh -oHostKeyAlgorithms=+ssh-dss user@127.0.0.1

or in the ~/.ssh/config file:

Host somehost.example.org

HostkeyAlgorithms ssh-dss

Depending on the server configuration, it's possible for other connection parameters to fail to negotiate.

You might find the Ciphers and/or MACs configuration options useful for enabling these.

It's also possible to query which algorithms ssh supports:

ssh -Q cipher # List supported ciphers

ssh -Q mac # List supported MACs

ssh -Q key # List supported public key types

ssh -Q kex # List supported key exchange algorithms

Finally, it's also possible to query the configuration that ssh is actually using when it is attempting to connect to a specific host using the -G option. For example:

ssh -G user@somehost.example.com

Will list all the configuration options, including the chosen values for the Ciphers, MACs, HostkeyAlgorithms and KexAlgorithms parameters.

更多精彩内容，请访问https://riboseyim.github.io
扫码关注公众号：@睿哥杂货铺