Sto provando a connettermi alla macchina uno con ssh e quindi connettersi a un'altra macchina due con ssh. Ma questo errore:Errore SSH durante l'esecuzione di un comando remoto: "stdin: non è un tty"
ssh [email protected] 'ssh [email protected]'
stdin: is not a tty
Quando si accede in un guscio, l'host remoto presuppone che la connessione è effettuata da un utente umano. Pertanto, è ragionevole aspettarsi che abbiano il controllo sullo standard in sul client. Vale a dire, l'utente sta dando input su un terminale attraverso la tastiera. Se l'host remoto rileva che l'utente non è umano (poiché l'input non è un terminale - tty, ma un altro processo), può avvisare l'utente di questa condizione imprevista.
Una dimostrazione del comportamento scorretto discusso e come evitarlo (man ssh e cercare -t per una spiegazione più approfondita).
$ ssh -t genja.org 'ssh raptor.lan hostname\; uptime'
host: genja.lan
raptor
21:17:27 up 3 days, 15 min, 1 user, load average: 0.00, 0.00, 0.00
Connection to genja.org closed.
$ ssh genja.org uptime
host: genja.lan
21:17:43 up 12 days, 17:40, 1 user, load average: 0.30, 0.08, 0.02
... e l'errore:
$ ssh genja.org 'ssh raptor.lan hostname\; uptime'
host: genja.lan
Permission denied (publickey,keyboard-interactive).
si consiglia di fare un tunnel, invece:
ssh -L 4444:raptor.lan:22 genja.org
Poi, su un terminale diverso:
ssh -p 4444 localhost will give you a conenction straight to "raptor.lan"
Utilizzare indirizzi IP come 192.168.0.11 se gli alias DNS non sono configurati sul terminale remoto.
Prova ad aggiungere il flag '-t' al primo' ssh'. A proposito, dal momento che la tua domanda non è legata alla programmazione, potrebbe essere più appropriata su http://superuser.com/ – aland
@aland Hai ragione. Con l'opzione -t run. – Jhonathan