screen -R não está funcionando com ssh

3

Eu tenho uma caixa de linux no escritório que eu quero usar no meu Macbook em casa. Não consigo alcançar a caixa diretamente na porta 22, mas tenho um túnel de porta pregado entre o localhost: 23001 e a porta 22 na caixa do Linux remoto. Isso funciona para uma sessão ssh regular:

$ ssh -t -2 -A -p 23001 [email protected]

O próximo passo é, eu quero executar automaticamente a minha sessão de terminal dentro de uma sessão de tela. Quase funciona para fazer:

$ ssh -t -2 -A -p 23001 [email protected]  screen -R

Se eu não tiver uma sessão de tela atual, ela criará uma. Se já houver uma tela desanexada, ela será conectada a ela. Por enquanto, tudo bem. Mas o problema é que eu nunca recebo um shell de login, então meu .profile nunca é executado e meu ambiente não é configurado. Então, fui um passo além e tentei:

$ ssh -t -2 -A -p 23001 [email protected]  bash -l -c screen -R

Agora, recebo um shell de login real que executa .profile, mas a tela não é anexada novamente a uma sessão desanexada. Eu corro o comando acima no meu Macbook, e no computador remoto, eu tenho uma tela anexada:

$ screen -list
There is a screen on:
    21117.pts-21.roysmith01 (01/19/2015 01:50:59 PM)    (Attached)
1 Socket in /var/run/screen/S-roysmith.

Se eu fechar a janela onde corri a linha ssh acima, a sessão será desanexada, como esperado:

$ screen -list
There is a screen on:
    21117.pts-21.roysmith01 (01/19/2015 01:50:59 PM)    (Detached)
1 Socket in /var/run/screen/S-roysmith.

Agora, se eu abrir outra janela de terminal local e executar o comando ssh novamente, a tela não conseguirá encontrar a sessão desanexada e criará uma nova:

$ screen -list
There are screens on:
    21304.pts-21.roysmith01 (01/19/2015 01:52:40 PM)    (Attached)
    21117.pts-21.roysmith01 (01/19/2015 01:50:59 PM)    (Detached)
2 Sockets in /var/run/screen/S-roysmith.

Alguma ideia do que está acontecendo aqui? Por que inserir um shell de login impede que a tela localize as sessões existentes?

    
por Roy Smith 19.01.2015 / 21:31

2 respostas

1

Se não houver uma sessão existente para se conectar, a tela usará o comando que você fornecer após o sinalizador -R . Então, isso deve fazer o que você quiser (sem ter que tocar em .screenrc):

$ ssh [...]@127.0.0.1 screen -R bash -l

(Esta é certamente a maneira mais simples de fazer o que você originalmente pretendia fazer.)

Mas desde que você perguntou, eu também mencionarei porque sua abordagem bash -l não funcionou. Foi tão perto!

bash -c leva apenas o próximo argumento como um comando. Argumentos depois disso vão para $0 , $1 , etc.

$ bash -c echo bar
[just a blank line]
$ bash -c 'echo foo'
foo
$ bash -c 'echo $1' foo bar baz
bar

Isso faz o que você queria que bash -l -c screen -R fizesse:

$ ssh [...]@127.0.0.1 bash -l -c "'screen -R'"

Sim, excitantemente você precisa de dois níveis de cotação para que isso funcione: as aspas externas dizem ao seu shell local para preservar as aspas internas, e as aspas internas são necessárias porque o ssh envia o comando resultante, bash -l -c 'screen -R' , como um string com quatro espaços, não como uma lista de quatro palavras. Com um nível de aspas, o shell remoto ainda veria bash -l -c screen -R .

Isso também seria feito, com o shell remoto recebendo a string de comando bash -l -c screen\ -R :

$ ssh [...]@127.0.0.1 bash -l -c 'screen\ -R'

Ou isso, para fornecer o shell remoto bash -l -c "screen -R" :

$ ssh [...]@127.0.0.1 bash -l -c \"screen -R\"
    
por 09.02.2015 / 06:24
0

Eu encontrei Como faço para pedir tela para se comportar como um shell bash padrão? , que me apontou na direção certa. Colocando "defshell -bash" no meu .screenrc obtém-me o comportamento que quero. No entanto, eu consegui descobrir o que a tela está realmente fazendo. Eu odeio encontrar coisas que funcionam sem entender o porquê.

    
por 20.01.2015 / 02:50