Das Produkt unseres Unternehmens ist eine Anwendung, die in einem Container ausgeführt wird. Es lauscht auf Port 2222, um eine Befehlszeilenschnittstelle einzurichten.
Ein Kunde hat Probleme mit SSH. Dieses Problem ist uns noch nie zuvor begegnet und kann nicht mit genau demselben Betriebssystem (RHEL 7.8), derselben Docker-Version (RHEL gepackt 1.13.1) + demselben Container (unsere App, dieselbe Version) reproduziert werden.
Wenn dies der Fall ist:
ssh -p 2222 <user>@<ip>
Die auf der Clientseite angezeigten Fehler sind:
server refused to allocate ptyoderPTY allocation request failed on channel 0
Die Fehlerprotokolle in unserer App (Server) sind:
openpty: Operation not permitted
session_pty_req: session 0 alloc failed
pam_unix(sshd:session): session closed for user <>
Wenn man das googelt, kann es sein, dass falsche Berechtigungen für /dev/pts, /dev/pts/ptmx oder /dev/ptmx vorliegen. Aber hier sind sie korrekt.
Eine weitere Möglichkeit ist, dass beim Mounten von Devpts gid=5 fehlt. Ich habe es überprüft und die Mounts sehen sowohl auf dem Host als auch im Container korrekt aus.
# 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
Ich habe mein System mit dem des Kunden verglichen. Es scheint alles zu passen, aber offensichtlich stimmt etwas nicht.
Ein weiterer Datenpunkt: Derzeit führen sie den Container mit docker run --user 100001:0 ...user-id=1000001, group-id=0 oder root aus. Wenn sie den Container stattdessen als root ausführen, docker run --user 0:0 ...tritt dieses Problem nicht auf. Es liegt irgendwo ein Berechtigungsproblem vor.
Ist das schon einmal jemandem passiert?
Ich wäre für jeden Hinweis sehr dankbar, da mir die Ideen ausgegangen sind.
Antwort1
Wir haben festgestellt, dass das Problem darin liegt, dass das NIS des Kunden TTY auf Gruppe 7 eingestellt hat.
Wir richten strace für den SSH-Prozess im Container ein. Wenn sie versuchen, sich per SSH anzumelden, versucht openpty(), chown auszuführen, und schlägt fehl. Wir sehen dies in den strace-Protokollen:
chown("/dev/pts/0", 1000001, 7) = -1 EPERM (Operation not permitted)
Als wir das dann taten, getent group | grep ttysahen wir, dass NIS TTY auf Gruppe 7 einstellte.
Dieser Fehler tritt nicht auf, wenn der Container als Root ausgeführt wurde (--user in Docker Run nicht angegeben) oder wenn der Docker-Container kein Host-Netzwerk verwendet.
Um dies zu beheben, müssen wir sicherstellen, dass die NIS-Einstellungen nicht in den Container gelangen. Bearbeiten Sie daher /etc/nsswitch.conf im Container und entfernen Sie nisdie Einträge passwd, shadow, und group.
Wenn jetzt eine SSH-Sitzung gestartet wird, wird /dev/pts/<> im Container mit der Containergruppe (der „richtigen“) erstellt und chown sollte nicht fehlschlagen.