O que pode impedir que o ssh seja anexado a uma sessão de 'tela' existente em um servidor remoto?

Question

O que impediria que o seguinte comando fosse anexado a uma sessão de tela existente em um servidor remoto?

ssh -t server2 "screen -dr admin"

As máquinas server1 e server2 possuem sessões de tela chamadas ' admin ' em execução. No server1, o comando é executado perfeitamente, reconectando-se à sessão de tela ' admin '. Mas, ao tentar o mesmo no server2, a conexão é fechada com esta mensagem:

"screen" isn't allowed to be executed.
Connection to server2 closed.

server1 /var/log/auth.log em uma nova anexação sucessiva à sessão de tela:

Jul 13 04:40:02 server1 sshd[3995]: Accepted publickey for dbkeys from 192.168.1.170 port 52434 ssh2: RSA a4:41:1e:62:66:33:35:5f:b0:d4:a7:cd:d9:b1:20:0d
Jul 13 04:40:02 server1 sshd[3995]: pam_unix(sshd:session): session opened for user dbkeys by (uid=0)
Jul 13 04:40:02 server1 systemd-logind[1144]: Removed session 9.
Jul 13 04:40:02 server1 systemd-logind[1144]: New session 10 of user dbkeys

server1 está executando o Linux Mint 17.3

server1 # uname -a
Linux server1 3.19.0-32-generic #37~14.04.1-Ubuntu SMP Thu Oct 22 09:41:40 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
server1 # cat /etc/issue
Linux Mint 17.3 Rosa \n \l

% de /var/log/auth.log de server2 na tentativa de nova anexação falhada de sessão de tela:

Jul 13 11:40:32 server2 sshd[21144]: Accepted publickey for dbkeys from 77.225.135.132 port 52437 ssh2: RSA SHA256:uidABN1IbiI7jQx10VmpWrbCGgyTkGwJaIHiiG6crPI
Jul 13 11:40:32 server2 sshd[21144]: pam_unix(sshd:session): session opened for user dbkeys by (uid=0)
Jul 13 11:40:32 server2 systemd-logind[546]: New session 203 of user dbkeys.
Jul 13 11:40:32 server2 sshd[21183]: Received disconnect from 77.225.135.132 port 52437:11: disconnected by user
Jul 13 11:40:32 server2 sshd[21183]: Disconnected from 77.225.135.132 port 52437
Jul 13 11:40:32 server2 sshd[21144]: pam_unix(sshd:session): session closed for user dbkeys
Jul 13 11:40:32 server2 systemd-logind[546]: Removed session 203.

o servidor 2 está executando o Ubuntu 16.04.2

root@server2:/var/log# uname -a
Linux audit.bitmark.io 4.4.0-83-generic #106-Ubuntu SMP Mon Jun 26 17:54:43 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
root@server2:/var/log# cat /etc/issue
Ubuntu 16.04.2 LTS \n \l

Os arquivos /etc/ssh/sshd _config do server1 e do server2 são idênticos

O que não está permitindo que screen seja executado no servidor2?

    

Answer 1

O problema foi o shell de login. No servidor 2, sudosh estava sendo usado como o shell de login, em vez de /bin/bash

Linha relevante em /etc/passwd :

dbkeys:x:1000:1000:DBKeys,,,:/home/dbkeys:/usr/local/bin/sudosh

mas, em /etc/sudosh.conf , o programa screen tem que ser explicitamente permitido:

# Sudosh Configuration File
logdir                  = /var/log/sudosh
default shell           = /bin/bash
delimiter               = -
syslog.priority         = LOG_INFO
syslog.facility         = LOG_LOCAL2
clearenvironment        = yes

# Allow Sudosh to execute -c arguments?  If so, what?
-c arg allow = scp
-c arg allow = rsync
-c arg allow = screen

Adicionando a linha -c arg allow = screen no final de sudosh.conf resolveu o problema.