Ssh
在 ssh 中不分配終端有什麼好處？
每隔一段時間我會做類似的事情
ssh user@host sudo thing並且提醒我 ssh 預設情況下不分配偽 tty。為什麼不呢？
ssh如果我別名為 ，我會失去什麼好處ssh -t？
主要區別在於互動性的概念。這類似於在腳本中本地執行命令，而不是自己輸入命令。不同之處在於遠端命令必須選擇預設值，非互動是最安全的。（通常是最誠實的）
標準輸入
- 如果分配了 PTY，應用程序可以檢測到這一點，並知道在不破壞任何東西的情況下提示使用者進行額外輸入是安全的。如果沒有終端，有很多程序會跳過提示使用者輸入的步驟，這是一件好事。否則會導致腳本不必要地掛起。
- 在命令執行期間，您的輸入將被發送到遠端伺服器。這包括控制序列。雖然
Ctrl-c中斷通常會導致 ssh 命令上的循環立即中斷，但您的控制序列將改為發送到遠端伺服器。這導致需要“敲擊”擊鍵以確保它在控制離開ssh 命令時但在下一個 ssh 命令開始之前到達。我會警告不要
ssh -t在無人看管的腳本中使用，例如 crons。要求遠端命令以互動方式進行輸入的非互動式 shell 會帶來各種麻煩。您還可以在自己的 shell 腳本中測試終端是否存在。使用較新版本的 bash 測試 STDIN：
# fd 0 is STDIN [ -t 0 ]; echo $?標準輸出
- 當別名
ssh為 時ssh -t，你可以期望在你的行尾得到一個額外的輸入。您可能看不到它，但它就在那裡；它會顯示為^M當管道傳輸到cat -e. 然後，您必須付出額外的努力來確保不會將該控制程式碼分配給您的變數，特別是如果您要將該輸出插入到數據庫中。- 還有一種風險是程序會假設它們可以呈現對文件重定向不友好的輸出。通常，如果您要將 STDOUT 重定向到文件，程序會辨識您的 STDOUT 不是終端並忽略任何顏色程式碼。如果 STDOUT 重定向來自ssh 客戶端的輸出，並且有一個與客戶端遠端端關聯的 PTY，則遠端程序無法進行這種區分，並且您最終會在輸出文件中出現終端垃圾。將輸出重定向到連接遠端端的文件仍應按預期工作。
這是與之前相同的 bash 測試，但針對 STDOUT：
# fd 1 is STDOUT [ -t 1 ]; echo $?雖然可以解決這些問題，但您不可避免地會忘記圍繞它們設計腳本。我們所有人都在某個時候做。您的團隊成員也可能沒有意識到/記得這個別名已經存在，這反過來會在他們編寫使用您的別名的腳本時給您帶來問題。
別名
ssh為ssh -t在很大程度上違反了最小意外的設計原則；人們會遇到他們沒有預料到的問題，並且可能不明白是什麼原因造成的。