O produto da nossa empresa é um aplicativo executado em um contêiner. Ele escuta na porta 2222 para estabelecer uma interface de linha de comando.
Um cliente está tendo problemas com SSH, nunca vimos esse problema antes e não podemos reproduzir exatamente com o mesmo sistema operacional (RHEL 7.8), versão Docker (pacote RHEL 1.13.1) + Container (nosso aplicativo, mesma versão).
Quando eles fazem:
ssh -p 2222 <user>@<ip>
Os erros que eles veem no lado do cliente são:
server refused to allocate ptyouPTY allocation request failed on channel 0
Os logs de erros em nosso aplicativo (servidor) são:
openpty: Operation not permitted
session_pty_req: session 0 alloc failed
pam_unix(sshd:session): session closed for user <>
Pesquisando isso no Google, uma possibilidade são permissões incorretas em: /dev/pts, ou /dev/pts/ptmx, ou /dev/ptmx. Mas eles estão corretos aqui.
Outra possibilidade é que a montagem de devpts esteja faltando gid=5. Eu verifiquei e as montagens parecem corretas tanto no host quanto no contêiner.
# 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
Verifiquei meu sistema com o do cliente. Tudo parece combinar, mas obviamente algo está errado.
Outro ponto de dados: atualmente eles executam o contêiner usando docker run --user 100001:0 ...where user-id=1000001, group-id=0 ou root. Se, em vez disso, eles executarem o contêiner como root docker run --user 0:0 ..., esse problema não ocorrerá. É um problema de permissão em algum lugar.
Alguém encontrou isso antes?
Qualquer sugestão seria muito apreciada, pois estou sem ideias.
Responder1
Descobrimos que o problema era que o NIS do cliente estava configurando o tty para o grupo 7.
Configuramos o strace no processo ssh dentro do contêiner. Quando eles tentam fazer ssh, openpty() tentará chown e falhará, vemos isso nos logs do strace:
chown("/dev/pts/0", 1000001, 7) = -1 EPERM (Operation not permitted)
Então, quando o fizemos, getent group | grep ttyvimos que o NIS estava configurando o tty para o grupo 7.
Essa falha não acontecerá se o contêiner estiver sendo executado como root (--user não especificado em docker run) ou se o contêiner do docker não estiver usando rede host.
Para corrigir isso, precisamos ter certeza de que as configurações do NIS não vazaram para o contêiner, então edite /etc/nsswitch.conf dentro do contêiner e remova nisas entradas passwd, shadowe group.
Agora, quando a sessão ssh for iniciada, /dev/pts/<> no contêiner será criado com o grupo de contêineres (o "correto") e chown não deverá falhar.