☰

奇怪的 SSH 問題，ssh 使用 -t 可以工作，但沒有它就會凍結

tag-icon • tag-icon shell ssh login
奇怪的 SSH 問題，ssh 使用 -t 可以工作，但沒有它就會凍結

當我ssh進入我的一台伺服器時，它似乎已登錄，但在給出提示之前掛起 ( message debug2: shell request accepted on channel 0 is the last log entry)。

儘管奇怪的是，當不起作用ssh -t "/bin/bash"時卻起作用。ssh

到目前為止我發現了什麼

  • 我可以正常從同一地理位置的伺服器登錄
  • 如果我ssh -t '/bin/bash'- 我可以從任何位置完美登入。
  • 如果我使用rsync 到伺服器，它似乎可以工作，然後鎖定
  • 如果我使用rsync 從伺服器，運行沒有問題

我嘗試過的

  • 刪除或更改所有登入選項.profile，.bashrc /etc/profile
  • 改變ssh_config 和/或 sshd_config到一台運作良好的相同伺服器
  • 我檢查了路由
  • 我請了網路專家檢查，tcpdump但無濟於事（儘管似乎確實有很多重傳）

我實在想不出其他什麼了

除了狡猾的網卡驅動程式/韌體之外。

答案1

這可能來自設定檔中的問題。
當你連接ssh -t /bin/bash 你的 shell 時，它不會“登入”，它不會來源/etc/profile，也~/.profile不會 ~/.bashrc...

因此，連接後，將 shell 置於調試模式，然後對每個檔案進行來源操作以查找內部阻塞的內容：

set -x 
. /etc/profile 
...and so on

編輯

請注意，我錯了，.bashrc 檔案將由任何互動式 shell 取得（因此這裡只有設定檔、profile.d 檔案很重要）。

嘗試列出連接過程的不同階段。像這樣的東西

1）ssh 連線（配置，...）
2）登入（PAM，tty，wtmp，...）
3）啟動 shell（設定文件，主目錄訪問，...）

若要檢查 (1)，您可以在偵錯模式下啟動 sshd 守護程式。為此，您需要啟動另一個 sshd，偵聽專用連接埠（不在連接埠 22 上，因此無需停止常規 sshd 守護程式）。

# /usr/sbin/sshd -p 2222 -ddd

該 sshd 將只接受一個連線並且不會進入背景。開啟另一個終端機並連接到該 ssh 會話。

# ssh -vvv -p 2222 user@host

您可以將收到的訊息與同一品牌的另一台伺服器的訊息進行比較。然後你就知道問題是否出在ssh端了。

（-ddd和-vvv是最大調試級別，您可以調整）

我明白了關聯，更詳細。

答案2

我的問題的答案 原來是網路問題。我最終發現，透過將所有網路卡的 MTU 降低一點，問題就消失了。

最有可能的是該網路的某些配置錯誤，但我現在可以證明這一點並將其移交給網路團隊（他們一直告訴我這是伺服器問題）。

但請注意，這是最後的手段 我的特點是 ssh 伺服器在同一子網路中工作，但不在其外部，並且 ssh -t '/bin/bash' 可以在任何地方工作。

我也有 rsyncs，可以正常啟動，但在某些時候只是掛起，或斷開連接。

因此，如果您正在查看這個答案，請先嘗試上面的其他答案，並且只有當您遇到像我這樣的奇怪問題時，這才可能有所幫助。

所以感謝所有的幫助。我嘗試了一切，它教會了我很多東西，並讓我確認它與伺服器無關（這就是我所希望的一切）。

所以感謝所有提供幫助的人

答案3

我最近使用嵌套虛擬化平台時遇到了相同的問題。

將來源伺服器或目標伺服器上的 MTU 從 1500 減少到 1400 後即可運作。

/sbin/ip link set dev eth0 mtu 1400

答案4

當你這樣做時ssh some_user@some_host /bin/bash，你所做的就是啟動某個用戶的 shell（定義於/etc/passwdon某個主機)，然後/bin/bash從該 shell 中執行給定的命令 。

現在，某個用戶的 shell（我們假設它也是bash）沒有以交互方式啟動（而是執行給定的命令）。所以它不會分配 pty (a偽終端），這意味著沒有 pty 可供發出的命令使用，因此它以非交互方式啟動。

在範例中，請求的/bin/bash命令已啟動，但似乎掛起。

您可以透過要求ssh建立一個 pty 來修復此問題，以便 shell 及其子進程可以使用該 pty。這就是作用-t。

    $ ssh -t some_user@some_host bash

您也可以透過強制命令建立 pty 來解決此問題。對於bash，您可以透過傳遞-i參數來完成此操作。以下命令列也應該有效：

$ ssh some_user@some_host bash -i

但請注意，在後一種情況下，shell 無法訪問/dev/tty，這會導致警告：

bash: no job control in this shell

原因如下：這裡。這可能是也可能不是問題，取決於您計劃在 shell 中執行的操作，但使用ssh -t可能是更好的選擇。

（請注意，您可以僅bash作為命令傳遞，因為無論如何它都應該位於使用者預設 shell 的路徑上）

相關內容