Por que recebo permissão negada erro ao sair da sessão SSH?

Question

Eu tenho que executar alguns testes em um servidor da Universidade. Eu tenho acesso ssh ao servidor da área de trabalho no meu escritório. Eu quero lançar um script python no servidor que irá executar vários testes durante o fim de semana.

A área de trabalho no escritório ficará em espera durante o fim de semana e, como tal, é essencial que o processo continue a ser executado no servidor, mesmo quando a sessão do SSH for encerrada.

Eu sei sobre nohup e screen e tmux , conforme descrito em perguntas como:

• Como manter os processos em execução após o término da sessão ssh?
• Como posso fechar um terminal sem matar o comando em execução nele?

O que estou fazendo agora é:

• ssh username@server
• tmux
• python3 run_my_tests.py - > este script faz um monte de subprocess.check_output de outro script que lança alguns processos Java.
• Os testes são executados corretamente.
• eu uso Ctrl + B, D e desanexo a sessão.
• Ao fazer tmux attach , eu obtenho a sessão tmux que ainda está funcionando bem, sem erros . Eu continuei verificando isso por minutos e os testes correm bem.
• Eu fecho a sessão ssh

Depois disso, se eu fizer login no servidor via SSH, eu faço conseguir reconectar a sessão tmux em execução, no entanto o que eu vejo é algo como :

Traceback (most recent call last):
  File "run_my_examples.py", line 70, in <module>
  File "run_my_examples.py", line 62, in run_cmd_aggr
  File "run_my_examples.py", line 41, in run_cmd
  File "/usr/lib64/python3.4/subprocess.py", line 537, in call
    with Popen(*popenargs, **kwargs) as p:
  File "/usr/lib64/python3.4/subprocess.py", line 858, in __init__
    restore_signals, start_new_session)
  File "/usr/lib64/python3.4/subprocess.py", line 1456, in _execute_child
    raise child_exception_type(errno_num, err_msg)
PermissionError: [Errno 13] Permission denied

Ou seja. o processo que gerava meus testes de execução, logo após o término da sessão SSH , era completamente incapaz de gerar outros subprocessos. Eu tenho chmod ed as permissões de todos os arquivos envolvidos e nada muda.

Eu acredito que os servidores usem o Kerberos para login / permissões, o servidor é o Scientific Linux 7.2.

Será possível que as permissões de geração de novos processos sejam removidas quando eu fizer logoff das sessões ssh? Existe algo que eu possa fazer sobre isso? Eu tenho que lançar vários testes, sem saber quanto tempo ou espaço eles vão levar ...

• A versão de systemd é 219
• O sistema de arquivos é o AFS, usando fs listacl <name> para confirmar se tenho permissões sobre os diretórios / arquivos usados pelo script.

Answer 1

Graças a Mark Plotnick , consegui identificar e corrigir o problema.

O problema é a interação entre o sistema de arquivos do AFS usado pelo servidor e o Kerberos lidando com a autenticação. O mesmo problema foi levantado em este pergunta sobre SO .

Basicamente, o que está acontecendo é que, quando eu ssh no servidor, o Kerberos fornece o token de autenticação para a sessão. Este token é usado também para acessar o sistema de arquivos do AFS. Ao fechar a sessão SSH, esse token é destruído e os processos em execução começam a obter permissão de erros negados ao tentar acessar arquivos no AFS.

A maneira de corrigir isso é iniciar uma nova janela dentro de screen / tmux e iniciar o comando:

kinit && aklog

Depois disso, você pode desanexar de screen / tmux e fechar a sessão ssh com segurança.

Os comandos acima criam novos tokens do Kerberos e os associam à sessão screen / tmux , desta forma, quando a conexão ssh é fechada, os tokens iniciais são revogados, mas como os subprocessos agora usam aqueles que você criou, don ' t sofrer permissão negada erros.

Para resumir:

• ssh username@server
• tmux
• Inicie o processo que você precisa para continuar executando
• Crie uma nova janela com Ctrl + B, C
• kinit && aklog
• Desanexe da sessão com Ctrl + B, D
• Fechar sessão ssh

Answer 2

Tais erros provavelmente estão relacionados às permissões do sistema de arquivos. Você pode dar uma olhada nos eventos syslog do lado do servidor?

Talvez você precise permanecer conectado ao seu ambiente Dê uma olhada aqui para saber mais sobre o arquivo Linux permissões e problemas, isso pode ajudar.

    

Answer 3

Experimente screen ssh $USER@$HOSTNAME no servidor.

A solução kinit && aklog não funcionou para mim, mas encontrei essa solução "sshception". Dentro da tela, eu ssh na mesma máquina e executo meus programas nessa sessão ssh. Mesmo que a tela perca a permissão, a sessão do ssh dentro permanece aberta e autenticada.