Impossibile creare nuove schermate quando si accede a un server tramite ssh

Quando connesso fisicamente al mio "server" (digitando i comandi dal desktop di un iMac di metà 2006), fornisce il seguente output:

mac~$ screen -ls
No Sockets found in /var/folders/ht/rhhsw0515vl_ym59683911400000gn/T/.screen.

bash$ screen -dmS foo
bash$ screen -ls
There is a screen on:
    4250.foo    (Detached)
1 Socket in /var/folders/ht/rhhsw0515vl_ym59683911400000gn/T/.screen.

bash$

Qual è il comportamento che ci si aspetterebbe. Tuttavia, quando si eseguono gli stessi comandi su SSH autenticato da RSA, il screen -dmS foocomando non sembra funzionare:

remote-bash$ screen -ls
No Sockets found in /var/folders/h4/_8scfsb54kd3mm7q6n9lq8nc0000gn/T/.screen.

remote-bash$ screen -dmS foo
remote-bash$ screen -ls
No Sockets found in /var/folders/h4/_8scfsb54kd3mm7q6n9lq8nc0000gn/T/.screen.

remote-bash$

Dopo aver provato il comando schermo standard, senza opzioni, l'intera shell si blocca e non può essere chiusa con ^ C.

Nota che posso vedere, collegarmi e uccidere le schermate avviate sul server, ma non posso avviarle su SSH.

C'è una spiegazione per questa incoerenza o il problema è peculiare alla mia macchina?

— catalogue_number
fonte

Risposte:

La prima cosa che mi viene in mente è che lo schermo della shell si avvia quando collegato tramite ssh muore immediatamente per qualche motivo. Prova a usare

screen -LdmS foo

invece e guarda il contenuto del file screenlog.0 per scoprirlo.

MODIFICA dopo commento OP:

sembra che lo schermo non sia in grado di avviare una shell. Immagino che il tuo server SSH non stia impostando correttamente la variabile d'ambiente SHELL o che la tua shell abbia bisogno di qualcos'altro per funzionare che il tuo server SSH non fornisce di default. Si prega di controllare l'output di

echo $SHELL

e quindi prova a eseguire manualmente la stessa shell (ovvero esegui il comando che vedi nell'output).

Inoltre, potrebbero esserci problemi di autorizzazione nel terminale. Sotto il mio OSX 10.9.5, proprio ora, che è / dev / ttys000, nel tuo caso puoi usare il comando who per scoprire il tuo. Lo schermo necessita dell'autorizzazione di scrittura per l'utente corrente su quel terminale. Ora ho letto nel tuo commento che le autorizzazioni nel tuo caso sono:

crw--w---- 1 sandersfamily tty 16, 1 7 Mar 23:31 ttys001

"Sandersfamily" è l'utente con cui stai effettuando l'accesso tramite ssh? Altrimenti, questo è il problema.

— Lucio Crusca
fonte

Ho eseguito il comando, ma l'esecuzione ls -a | grep screennon ha restituito nulla nelle directory ~ / o /.

— catalogue_number

$SHELLrestituisce /bin/bashsolo l' eco

— numero_codice

cosa succede se avvii un / bin / bash da solo invece dello schermo? Funziona?

— Lucio Crusca,

il lancio / bin / bash funziona perfettamente, è solo screenche si comporta in modo strano.

— catalogue_number

E i bit di autorizzazione del terminale? (vedi nuova modifica nella mia risposta).

— Lucio Crusca,

Ho trovato il problema!

Si scopre che, per un motivo o per l'altro, lo schermo non può scrivere senza che PAM sia abilitato. Avevo in precedenza letto che, anche se PasswordAuthenticaitone ChallengeResponseAuthenticationsono impostati no, PAM è ancora una vulnerabilità, così ho disattivato nel /etc/sshd_configfile.

È bastato cambiare UsePAM no in UsePAM yesin /etc/sshd_confige il comando funziona come previsto. Non so se c'è un modo di usare screensenza che PAM sia abilitato, ma non credo che sia un problema di sicurezza particolarmente grave per i miei scopi.

— catalogue_number
fonte