簡短的介紹
多年來我一直在 SSH 連接上看到奇怪的行為,但直到今天才想到提出問題。我嘗試對此進行了很多搜索,但找不到任何原因。
環境
- 基本上,我在不同區域(如愛爾蘭、孟買等)運行各種 AWS EC2 執行個體。
- 我有一台Mac。
- 我位於印度(以防有人出於某種原因感到震驚)。
問題陳述1
當我的 Mac 透過 4G 網路連接到個人熱點(從三星裝置或 iPhone)時,如果我不進行 SSH 會話(基本上, SSH 連線非常理想)。所以我必須一直按箭頭鍵才能讓它保持活力。
問題陳述2(這不是問題)
但當我的Mac連接到Wifi寬頻連線時,這個問題就不會出現。即使我將 Mac 從睡眠狀態中喚醒(打開蓋子),我的 SSH 連線仍會保持連線數小時。
今天再次根據我的谷歌搜索,我發現了各種文章,這些文章提供了使用諸如TCPKeepAlive
或 之類的選項的解決方案ServerAliveInterval
:
- sshd_config 中的 `ServerAliveInterval` 和 `ClientAliveInterval` 選項到底有什麼作用?
- tcp-keepalive 在 ssh 中如何運作?
- https://raspberrypi.stackexchange.com/questions/8311/ssh-connection-timeout-when-connecting
- https://patrickmn.com/aside/how-to-keep-alive-ssh-sessions/
但我找不到任何說明這個問題的帖子。你們有人對這種行為有任何想法嗎?我很樂意向您提供有關我的 4G 熱點連接的任何可能的詳細資訊。
答案1
我猜測是系統追蹤(並忘記)連接狀態導致了這種情況。當使用 NAT 時(不使用 IPv6 時經常出現這種情況),執行 NAT 的系統通常需要一個記憶體來記住要向何處發回回應。對於您的 Wifi 寬頻,執行 NAT 的系統可能有更長的記憶體來記住活動連線(例如,Linux網路過濾器的連線預設情況下,它會記住 TCP 連線 5 天,而它會記住 UDP 流 2 或 3 分鐘)。在 4G 路徑上執行 NAT 的等效系統的記憶體可能較短,略小於 300 萬。
要解決此問題,正如您在問題中找到並連結的那樣,您可以設定特定的 ssh 參數ServerAliveInterval
當沒有活動時,會定期發送空資料(如 SSH 協定),類似於TCP 保活。這將使執行 NAT 的系統始終將連接視為活動的,並且不會忘記它。所以在你的~/.ssh/config
文件中你可以加入:
ServerAliveInterval 115
115 的值選擇略小於 2mn 以保持保守:該值低於路徑中不可見 NAT 設備上活動連接的估計追蹤持續時間,但也不會太低(見下文)。因此,更糟的是,當追蹤狀態距離即將被刪除還有 5 秒時,它會回到假設的 120 秒壽命。
缺點是(無論如何在你的 Wifi 寬頻存取上)如果你失去連線一段時間然後恢復它,這可能會讓客戶端認為遠端伺服器已關閉並且它會關閉連線。您也可以調整ServerAliveCountMax
為此,但無論如何,如果預設值為 3,則需要 3*115=345 秒的連線遺失,超過 500 萬,才有機會出現此問題。
伺服器端有一個等效的ClientAliveInterval
sshd_config
您可以出於相同的目的在其文件中進行設定。這樣做的另一個好處是,當客戶端無論如何都失去連接時,不會在一段時間內保留 Ghost ssh 客戶端連接,這些連接被視為仍然連接。