SSH trava. error: openpty: Nenhum arquivo ou erro de diretório: session_pty_req: session 0 alloc failed

1

Um dos nossos servidores de produção Ubuntu 14.04 parou de aceitar conexões SSH. Quando tentamos fazer o login, obtemos o texto do Banner SSH, mas ele simplesmente trava. Se fizermos login usando o console de gerenciamento, poderemos ver as seguintes mensagens de erro em /var/log/auth.log

Oct  4 17:37:20 servername sshd[10975]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
Oct  4 17:37:21 servername sshd[10975]: Accepted publickey for username from 10.0.0.1 port 57230 ssh2: RSA xx:xx:xx:xx
Oct  4 17:37:21 servername sshd[10975]: pam_unix(sshd:session): session opened for user username by (uid=0)
Oct  4 17:37:25 servername sshd[10975]: error: openpty: No such file or directory
Oct  4 17:37:25 servername sshd[6869]: error: session_pty_req: session 0 alloc failed

Usando cat /proc/mounts| grep devpts; ls -hal /dev/{pts,ptmx} , posso verificar se ele existe e se tem as permissões corretas e se não há problemas de disco / inode:

devpts /dev/pts devpts rw,nosuid,noexec,relatime,mode=600,ptmxmode=000 0 0

crw-rw-rw- 1 root tty  5, 2 Oct  4 17:01 /dev/ptmx

/dev/pts:
total 0
drwxr-xr-x  2 root root       0 Aug 14 00:52 .
drwxr-xr-x 17 root root    4.3K Oct  4 17:01 ..
crw--w----  1 root tty  136, 18 Oct  4 17:41 18
crw--w----  1 root tty  136, 24 Oct  1 13:57 24
crw--w----  1 root tty  136,  3 Oct  4 17:39 3
crw--w----  1 root tty  136, 30 Oct  4 11:29 30
c---------  1 root root   5,  2 Aug 14 00:52 ptmx

df -h
    Filesystem      Size  Used Avail Use% Mounted on
    udev            252G  4.0K  252G   1% /dev
    tmpfs            51G   53M   51G   1% /run
    /dev/sdi2       220G   13G  197G   6% /
    none            4.0K     0  4.0K   0% /sys/fs/cgroup
    none            5.0M     0  5.0M   0% /run/lock
    none            252G   12K  252G   1% /run/shm
    none            100M     0  100M   0% /run/user
    /dev/sdi1        75M   512   75M   1% /boot/efi
    /dev/md1        3.5T  282G  3.0T   9% /ssd

df -hi
    Filesystem     Inodes IUsed IFree IUse% Mounted on
    udev              63M   526   63M    1% /dev
    tmpfs             63M   725   63M    1% /run
    /dev/sdi2         14M  171K   14M    2% /
    none              63M     2   63M    1% /sys/fs/cgroup
    none              63M     1   63M    1% /run/lock
    none              63M     4   63M    1% /run/shm
    none              63M     4   63M    1% /run/user
    /dev/sdi1           0     0     0     - /boot/efi
    /dev/md1         224M    46  224M    1% /ssd

Também verifiquei se o sshd_config corresponde a outro servidor e reiniciei o serviço ssh. Eu acredito que o sistema devpty é montado na inicialização, mas existe alguma maneira de resolver o problema sem reiniciar o servidor?

Eu vejo que o link tem uma solução não verificada para esse problema no RedHat, mas eu não tenho acesso a um RedHat Assinatura.

    
por Greg Bray 04.10.2018 / 20:43

2 respostas

1

Descobri que poderia obter uma sessão ssh não baseada em tty para funcionar usando:

$ ssh username@servername /bin/bash -i

bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
username@servername:~$ 

Eu acho que neste caso o erro ioctl é esperado, porque eu estou começando uma sessão interativa em algo que não tem um tty. Muitas coisas têm problemas nesta sessão (o termo env env não está definido), mas eu consegui fazer alguns problemas básicos e descobri isso:

#View a process list with parent process details
ps -axfo pid,uname,cmd | grep badservice | wc -l
27917

Basicamente, descobrimos que um dos nossos serviços tinha mais de 27900 processos rodando sob seu nome de usuário, quando comparamos isso com o bom servidor

$ salt 'server*' cmd.run 'ps -aux | grep badservice | wc -l'
server.good:
    3
server.bad:
    27918

Provavelmente isso estava causando algum tipo de esgotamento de recursos relacionado a ptys. O serviço ruim foi interrompido e eu matei todos os processos restantes para esse usuário usando sudo kill -u badservice . Depois disso, o SSH começou a funcionar como esperado novamente!

    
por 04.10.2018 / 22:58
0

Eu verifiquei outro servidor que estava funcionando e percebi que as opções de montagem eram um pouco diferentes:

Bad Server:  devpts /dev/pts devpts rw,nosuid,noexec,relatime,mode=600,ptmxmode=000 0 0
Good Server: devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0

Eu tentei o seguinte, que foi capaz de alterar as permissões de montagem para corresponder ao bom servidor:

sudo mount -o remount /dev/pts
sudo grep devpts /proc/mounts

devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0

Mas eu ainda recebo os mesmos erros tentando conectar (mesmo depois de reiniciar o ssh novamente).

    
por 04.10.2018 / 20:43