OpenSSH7.0兼容性測試報告

  背景

 2015年下，某省運營商綜合網絡管理系統。

按照安全管理要求，需對全系統主機的OpenSSH版本升級。

  第一次測試：系統自有服務器

   主機：RedHat Linux ／SunOS：系統內所有主機升級，內部互通沒有問題

  第二次測試：主機到網絡設備SSH互通性   

   國外廠商

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

    目前僅支持diffie-hellman-group1-sha一、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 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
掃碼關注公衆號：@睿哥雜貨鋪