我們公司的產品是一個運行在容器中的應用程式。它偵聽連接埠 2222 以建立命令列介面。
客戶遇到SSH 問題，我們以前從未見過此問題，並且無法使用完全相同的作業系統（RHEL 7.8）、Docker 版本（RHEL 打包的1.13.1）+ 容器（我們的應用程序，相同版本）重現。
當他們這樣做時：
ssh -p 2222 <user>@<ip>
他們在客戶端看到的錯誤是：
server refused to allocate pty或者PTY allocation request failed on channel 0
我們的應用程式（伺服器）中的錯誤日誌是：
openpty: Operation not permitted
session_pty_req: session 0 alloc failed
pam_unix(sshd:session): session closed for user <>
谷歌搜索，可能是以下權限不正確：/dev/pts、/dev/pts/ptmx、或/dev/ptmx。但他們在這裡是正確的。
另一種可能性是 devpts 的安裝缺少 gid=5。我檢查了一下，主機和容器上的安裝看起來都是正確的。
# Host
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
# Container
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
我已經將我的系統與客戶的系統進行了交叉檢查。一切看起來都很匹配，但顯然有些不對勁。
docker run --user 100001:0 ...另一個資料點：目前他們使用user-id=1000001、group-id=0 或 root來運行容器。相反，如果他們以 root 身份運行容器docker run --user 0:0 ...，則不會出現此問題。這是某個地方的權限問題。
以前有人遇到過這種情況嗎？
任何提示將不勝感激，因為我沒有想法。
答案1
我們發現問題是客戶的 NIS 將 tty 設定為群組 7。
我們在容器內的 ssh 進程上設定 strace。當他們嘗試 ssh 登入時，openpty() 將嘗試 chown 並失敗，我們在 strace 日誌中看到這一點：
chown("/dev/pts/0", 1000001, 7) = -1 EPERM (Operation not permitted)
然後，當我們這樣做時getent group | grep tty，我們看到 NIS 將 tty 設定為群組 7。
如果容器以 root 身分執行（--在 docker run 中未指定使用者），或 docker 容器未使用主機網絡，則不會發生此故障。
要解決此問題，我們需要確保 NIS 設定不會洩漏到容器中，因此在容器內編輯 /etc/nsswitch.conf，並刪除、和nis條目。passwdshadowgroup
現在，當啟動 ssh 會話時，將使用容器群組（「正確的」群組）建立容器中的 /dev/pts/<>，並且 chown 不應失敗。