网络设备OpenSSH7.0兼容性测试报告

OpenSSH7.0做出了一些变更，默认禁用了一些较低版本的密钥算法。受此影响，在同一系统中的主机、网络设备必须同步升级，或者开启兼容选项。实测中，也有某些厂家产品内核的原因，甚至无法升级。由此案例，关于系统版本管理、安全、架构、开源文档，甚至采购方面，都可以引发很多思考。

背景

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

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

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

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

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

国外厂商

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

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

当然不排除今年国产化运动影响，国外厂商维保过期等原因导致的售后升级服务滞后。

国内厂商

华为，无论是城域骨干网设备，还是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 releaseincluding:

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

* Several ciphers will be disabled by default: blowfish-cbc,cast128-cbc, all arcfour variants and the rijndael-cbc aliasesfor 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, legacyand/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 athttp://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: