SSH 遠端埠轉發失敗
**跟進：**看起來在執行每台伺服器幾個月後出現的一系列快速斷開連接可能是巧合，只是為了揭示實際問題。它無法重新連接的原因幾乎可以肯定是由於 AliveInterval 值（kasperd 的回答）。使用 ExitOnForwardFailure 選項應該允許在重新連接之前正確發生超時，這應該可以解決大多數情況下的問題。MadHatter 的建議（kill 腳本）可能是確保即使其他一切都失敗也能重新連接隧道的最佳方式。
我在防火牆後面有一個伺服器（A），它在幾個埠上啟動一個反向隧道到一個小型 DigitalOcean VPS（B），這樣我就可以通過 B 的 IP 地址連接到 A。該隧道已經連續工作了大約 3 個月，但在過去的 24 小時內突然發生了四次故障。不久前，另一家 VPS 提供商也發生了同樣的事情——幾個月的完美執行，然後突然出現多次快速故障。
我在機器 A 上有一個腳本，它自動執行隧道命令（
ssh -R *:X:localhost:X address_of_B對於每個埠 X），但是當它執行時，它說Warning: remote port forwarding failed for listen port X。進入
/var/log/secure伺服器上的 sshd 會顯示以下錯誤：bind: Address already in use error: bind: Address already in use error: channel_setup_fwd_listener: cannot listen to port: X解決需要重啟 VPS。在那之前，所有重新連接的嘗試都會給出“遠端埠轉發失敗”的消息並且將不起作用。現在到了隧道只持續大約 4 小時才停止的地步。
VPS 上沒有任何變化，它是一台一次性使用的單使用者電腦，僅用作反向隧道端點。它在 CentOS 6.5 上執行 OpenSSH_5.3p1。當連接失去時，sshd 似乎沒有關閉其末端的埠。我不知道為什麼，或者為什麼它會在幾個月幾乎完美的操作後突然發生。
為了澄清，我首先需要弄清楚為什麼 sshd 在隧道失敗後拒絕監聽埠，這似乎是由於 sshd 讓埠保持打開狀態並且從不關閉它們造成的。這似乎是主要問題。我只是不確定在我預期的幾個月的行為之後會導致它以這種方式執行（即立即關閉埠並允許腳本重新連接）。
我同意 MadHutter 的觀點，它很可能是來自失效 ssh 連接的埠轉發。即使您目前的問題被證明是其他問題，您也可能遲早會遇到這種失效的 ssh 連接。
這種失效連接可以通過三種方式發生：
- 兩個端點之一重新啟動，而連接的另一端完全空閒。
- 兩個端點之一關閉了連接，但在關閉連接時，連接出現了臨時中斷。連接關閉後中斷持續了幾分鐘，因此另一端從未了解關閉的連接。
- 連接在 ssh 連接的兩個端點上仍然完全正常，但是有人在它們之間的某個位置放置了一個有狀態的設備，由於空閒而導致連接超時。這個有狀態的設備可以是 NAT 或防火牆，您已經提到的防火牆是主要嫌疑人。
弄清楚以上三個中的哪一個正在發生並不是很重要，因為有一種方法可以解決所有三個問題。那就是使用keepalive消息。
您應該查看
ClientAliveInterval關鍵字 forsshd_config和or的ServerAliveInterval間隔。ssh_config``~/.ssh/config
ssh在循環中執行命令可以正常工作。在循環中插入睡眠也是一個好主意，這樣當連接由於某種原因失敗時，您不會最終淹沒伺服器。如果客戶端在伺服器上的連接終止之前重新連接，您可能會遇到新的 ssh 連接處於活動狀態但沒有埠轉發的情況。為了避免這種情況，您需要
ExitOnForwardFailure在客戶端使用關鍵字。