即如標題所示，DR 最近開始體會到這會是個問題……因著各種不一的因素，有些時候可能會遇到主機設備上存在著非常陳舊的 SSH 服務。它所支援及啟用的加密演算法，在較新的 Linux 系統上，若嘗試以 OpenSSH 的 ssh 客戶端指令連線過去，會出現例如以下錯誤：「no matching host key type found. Their offer: ssh-rsa,ssh-dss」。而這些陳舊設備裡，有些是 Linux、也有些是某種封閉系統。其中後者即代表它的軟體環境是無法被更動的，連線障礙無論如何都只能從客戶端解決。
上網查了一下，常見的解法是在執行 ssh 指令時加上「-oHostKeyAlgorithms=+ssh-dss」參數來加以排除。這在 WSL1 下安裝的 Ubuntu 24.04 系統，確認是可以運作的。然而當 DR 想要在公司以外的地方，執行相同的任務時。由於自己所使用的幾台老筆電多半是裝 RHEL 9，這才發覺 RHEL 9 在這方面是另有更多阻礙，而且難以排除。
不僅前述的解法無用，也參考了 Red Hat 說明文件，包含 update-crypto-policies 的使用說明在內， 並且嘗試不同的 ssh 參數及組合，然後用「ssh -vvv」去查詢更多執行過程的細部資訊，卻終究似乎還是有無法跨越的障礙。這樣的景況有點令人驚訝，因為總不能搞到最後，結論是要特別準備一套很舊的 Linux 系統來應對這種情形，若是這樣，在工作上實在不是很便利。
於是開始思考，能否在無須異動系統及軟體環境的情況下，使用其它版本的 SSH 客戶端程式來滿足需求。那麼在這樣的思路下，首先發現若用 Wine 跑 Windows 版的 PuTTY 可行，可以順利連線，然而很難說這是個值得推薦的辦法。於是再想了一下，則回想起許多年前曾經在 Nokia N900 上使用過 Dropbear SSH。發現它在 RHEL 9 上也很容易安裝，EPEL 套件庫有提供一個 2020.80 的版本，在有啟用該套件庫的情況下便使用 dnf 指令安裝即可：
- sudo dnf install dropbear
完成安裝後，單純地改用 Dropbear 所提供的 dbclient 客戶端程式，取代 ssh 指令來連線至 SSH 伺服器，就能夠順利連線，也不需要任何繁雜的操作或額外參數。至於倘若有從舊版本 SSH 伺服器進行檔案傳輸的需求，則 rsync 或 scp 指令也可以改為呼叫 dbclient，指定的參數如下所示：
- rsync -e "dbclient"
- scp -S "dbclient"
不過另一方面，DR 自己在家的桌機系統則是 Fedora 42。雖然它的套件庫本身就有提供 Dropbear 可安裝，然而版本（2025.89）有點太新了，會同樣地無法連線至舊的 SSH 服務。所以對此情形，直接的解決方案就是自行下載舊版的 Dropbear 原始碼，然後編譯及安裝：
- wget https://matt.ucc.asn.au/dropbear/releases/dropbear-2020.80.tar.bz2
- tar jxvf dropbear-2020.80.tar.bz2
- cd dropbear-2020.80/
- ./configure
- make
- sudo make install
或者，如有必要，倘若是自行撰寫客戶端程式來連接 SSH（例如使用 Python 的 paramiko 函式庫），那麼在 Fedora/RHEL 環境下，則可使用以下指令放行必要的條件，也能夠形成順利連線的結果：
- sudo update-crypto-policies --set DEFAULT:SHA1