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:
ssh -G user@somehost.example.com
Will list all the configuration options, including the chosen values for the Ciphers, MACs, HostkeyAlgorithms and KexAlgorithms parameters.
