網路設備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公開發布。

延伸：開源組件演進追蹤

本案例實際操作過程中，開頭走了很多彎路，並沒有一下找到要害。

根源在於團隊缺乏關注開源產品演進方向的意識和習慣，也缺乏直接閱讀、理解官方文檔的習慣。

更多精彩內容，請前往》RiboseYim 》閱讀原文，掃碼關注公眾號：@睿哥雜貨鋪

推薦閱讀：