Perché sshd non usa uno pseudo terminale quando l'argomento del client ssh è seguito da un programma interattivo?

Il modo normale di connettersi a un server SSH è ssh username@ip_address. Ma un utente potrebbe voler eseguire solo un programma sul computer remoto. Quindi il nome del programma segue l'argomento normale che è ssh username@ip_address <program_name>. Ad esempio ssh username@ip_address ls,. Tale argomento va bene tranne che per i programmi interattivi (che accettano anche l'input dell'utente oltre a fornire output) ad es top. L'output è

Variabile d'ambiente TERM non impostata.

il che significa che nessun terminale (pseudo-) è collegato tra i programmi sshd e top. La soluzione è aggiungere l'argomento in -tcui l'intero comando ora diventa ssh -t username@ip_address top.

La mia domanda è perché sshd non può usare di default anche uno pseudo-terminale per comunicare con programmi non interattivi, quindi non è necessario aggiungere l' -targomento per i programmi interattivi?

ssh pty

— Ron Vince
fonte

La risposta breve è "perché di solito non è quello che vuoi".

— Celada,

Prevedo che la tua domanda verrà moderata essenzialmente per chiedere un'opinione / lamentarsi. Ma giriamo la domanda: perché ssh dovrebbe allocare risorse tty quando non è richiesto nella stragrande maggioranza dei casi? La vera domanda è: perché l'allocazione forzata non è un'opzione di configurazione in modo da renderla un valore predefinito o specifico dell'host?

— Otheus,

@Otheus Si è un'opzione di configurazione. Puoi impostare RequestTTY yes(o force) nella tua configurazione.

— Jakuje,

Ehm davvero. Sembra essere stato introdotto in 6 ma difettoso fino a poco dopo. Uso solo distribuzioni molto vecchie. :)

— Otheus,

In che modo SSH può sapere in modo affidabile che un programma è interattivo? Anche toppuò funzionare in modalità batch.

— Muru,

Risposte:

È vero che, come altri hanno già detto, i PTY hanno un certo sovraccarico, ma il motivo principale per cui non si utilizza un PTY quando si esegue un comando remoto è che si perdono informazioni.

Normalmente, quando si esegue un comando da remoto tramite ssh, i comandi stdoute gli stderrstream vengono inviati al locale stdoute stderr, il che significa che è possibile reindirizzarli / reindirizzarli separatamente, ad esempio:

$ ssh server ls foo bar
ls: cannot access bar: No such file or directory
foo
$ ssh server ls foo bar > stdout 2> stderr
$ cat stdout
foo
$ cat stderr
ls: cannot access bar: No such file or directory

Ma se usi un PTY, tutto l'output va a stdout, perché i PTY non hanno flussi separati per output / errore:

$ ssh -t server ls foo bar > stdout 2> stderr
$ cat stdout
ls: cannot access bar: No such file or directory
foo
$ cat stderr
$

— psmears
fonte

Questo è un buon punto di cui non ero a conoscenza.

— Jakuje,

@ThomasDickey: Difficilmente ... la domanda non è "qual è la ragione storica alla base della scelta degli sviluppatori di questo default", ma "perché non è possibile utilizzare un pseudo-terminale di default" (l'enfasi è mia, ma il la formulazione è più o meno diretta dalla domanda). Quindi la differenza di comportamento (che spezzerebbe una serie di idiomi di scripting) è rilevante, indipendentemente da come gli sviluppatori hanno fatto questa scelta :-)

— psmears

@ThomasDickey: hai mai letto la domanda? Dove menziona l'opinione degli sviluppatori?

— psmears,

+1 indica un vantaggio specifico di non usare un pty (diverso dalle prestazioni). Potresti ancora sostenere che -tdovrebbe essere l'impostazione predefinita e un'opzione richiesta per disattivarla, quindi il vantaggio in termini di prestazioni minori è ciò che ha più senso per i casi in cui non importa.

— Peter Cordes,

La pagina di manuale per sshdescrive questo:

Quando l'identità dell'utente è stata accettata dal server, il server esegue il comando dato in una sessione non interattiva o, se non è stato specificato alcun comando, accede alla macchina e fornisce all'utente una normale shell come sessione interattiva . Tutte le comunicazioni con il comando remoto o la shell verranno automaticamente crittografate.

È caratteristica e probabilmente causata da ragioni storiche di rshcomportamento. È abbastanza ragionevole. La maggior parte dei comandi non è realmente interattiva e non è un'operazione libera per allocare PTY (che era più importante 20 anni fa).

— Jakuje
fonte

Le questioni relative alle risorse sono plausibili, ma il commento rshè oscuro poiché quel programma non ha opzioni corrispondenti.

— Thomas Dickey,

@ThomasDickey Non l'ho mai usato rsh, ma c'è sicuramente qualche influenza, non nelle opzioni, ma nel comportamento di rshe rlogin(se c'è comando o no). Non è possibile eseguire un comando interattivo (come rogue (6) o vi (1)) utilizzando rsh; utilizzare invece rlogin (1). .

— Jakuje,

Come si sshpuò dire se il comando che si sta invocando è interattivo o no?

Questo incubo peggiora quando ti rendi conto che potresti accedere a una macchina che esegue un sistema operativo non unix.

Non essendoci una soluzione semplice, un caso doveva essere quello predefinito.

— dmckee --- gattino ex moderatore
fonte

Non lo sa Non può saperlo E quindi abbiamo una pagina di manuale che descrive il comportamento in queste situazioni.

— Jakuje,