Come posso passare una variabile d'ambiente tramite un comando ssh? [duplicare]


43

Come posso passare un valore in un comando ssh, in modo tale che l'ambiente che viene avviato sul computer host inizi con una determinata variabile d'ambiente impostata su mia scelta?

EDIT: L'obiettivo è passare l'attuale desktop kde (da dcop kwin KWinInterface currentDesktop) alla nuova shell creata in modo che io possa restituire le posizioni di un nfs alla mia istanza JEdit sul server originale che è unico per ogni desktop KDE. (Utilizzando un meccanismo come emacsserver / emacsclient )

Il motivo per cui più istanze ssh possono essere in volo contemporaneamente è perché quando sto configurando il mio ambiente, sto aprendo un sacco di istanze ssh diverse su macchine diverse.

Risposte:


19

Il ~/.ssh/environmentfile può essere utilizzato per impostare le variabili desiderate disponibili per i comandi remoti. Dovrai abilitare PermitUserEnvironmentnella configurazione sshd.

Le variabili impostate in questo modo vengono esportate in processi secondari, quindi è possibile:

echo "Foo=Bar" > sshenv
echo "Joe=37" >> sshenv
scp sshenv user@server:~/.ssh/environment
ssh user@server myscript

e myscript saprà che Foo è Bar e Joe ha 37 anni.


3
la variabile deve cambiare potenzialmente ogni chiamata ssh
Ross Rogers,

1
Potrebbe essere meglio descrivere cosa stai cercando di fare e perché. Potrebbero esserci altre soluzioni. Il file di ambiente dovrebbe essere generato dinamicamente ad ogni chiamata ssh, il che non è impossibile.
EmmEff,

Cosa cambierà? I valori di quelle variabili o addirittura i loro nomi?
InnaM,

2
Questa risposta non sembra davvero rispondere alla domanda.
intuito il

1
Ciò si interromperà se due processi tentano di farlo contemporaneamente con diversi set di valori
nafg

55

L' SendEnvopzione è il tuo ragazzo.

~ / .ssh / config: (localmente)

SendEnv MYVAR

/ etc / ssh / sshd_config: (sull'estremità remota)

AcceptEnv MYVAR

Ora, qualunque sia il valore di $MYVARlocalmente, diventa disponibile anche nella sessione remota.
Se accedi più volte, ogni sessione avrà una sua copia di $MYVAR, con valori possibilmente diversi.

~/.ssh/environmentè pensato per altri scopi. In genere agisce come $ENVfile quando si eseguono comandi non shell da remoto.


6
può anche essere passato (in modo più utile) attraverso la riga di comando come ssh myserver -o SendEnv="MYVAR", quindi puoi renderlo dinamico negli script.
Mike Campbell,

31

È possibile passare valori con un comando simile al seguente:

ssh username@machine VAR=value cmd cmdargs

Puoi provare con:

ssh machine VAR=hello env

Su tcsh sembra funzionare quanto segue:

ssh machine "setenv VAR <value>; printenv"

Sembra che funzioni bene per gli ambienti bash. Peccato che io sia in un ambiente tcsh aziendale.
Ross Rogers,

2
Come posso usare la sessione in modo interattivo?
luckydonald

1
Si noti che il primo esempio funziona solo per il primo comando se si stanno concatenando i comandi insieme (con &&). Usando bash, export VAR=value;invece di setenv nel terzo modulo, funziona per questo caso.
contrebis,

2
Questo è quello che ho finito per fare! Ovunque tu vada, porta il tuo ambiente con te. Il tuo può farlo così: ssh user@host "$(<env_to_source.sh) command ..." . In env alla fonte, ho export var=value ; su righe separate (ricorda il punto e virgola).
Tomasz Gandor,

@TomaszGandor: anni dopo, ancora perfetto - mi permette persino di passare cose complesse come PROMPT_COMMAND lassù senza doversi preoccupare di scappare :-) 1000 grazie.
Red Pill

29

C'è anche un orribile, orribile hack.

Se il tuo script utilizza la variabile sull'estremità remota (ovvero puoi nominarla come preferisci), puoi abusare delle variabili locali. Qualsiasi variabile del modulo LC_ * verrà trasmessa testualmente, senza alcun requisito di configurazione.

Ad esempio, abbiamo una serie di server bastione in uno dei miei clienti. Odio dovermi connettere ad esso, solo per collegarmi a un altro server ... e un altro server ... ogni volta. Ho una sceneggiatura che si comporta proprio come SSH, tranne per il fatto che è intelligente.

Fondamentalmente, se è impostato LC_BOUNCE_HOSTS, lo divide in spazi e si stacca dal primo host. Quindi rimbalza ed esegue lo stesso script. Sul nodo di destinazione, questo elenco è infine vuoto, quindi esegue il comando. Ho anche una modalità di debug (che è eccezionale durante i problemi di rete), che è impostata da LC_BOUNCE_DEBUG. Dal momento che ssh mi trasmette tutto magicamente per me, non devo fare altro che riconoscere la fine della lista degli host (cosa che faccio con un'opzione -).

Mi sento sporco ogni volta che lo uso, ma funziona ovunque l'ho provato.


2
Perché dovresti usare qualcosa del genere invece ProxyCommanddell'opzione integrata di OpenSSH ? Modifica il tuo ~/.ssh/confige aggiungi un blocco simile Host *.example.com: ProxyCommand -ssh -W %h:%p bastionhoste lascia che tunnel le tue connessioni per te.
Kirk Strauser,

1
Per i tunnel, non è poi così male. Per vari motivi, due motivi: uno, PermitUserEnvironment richiede l'accesso dell'amministratore per la configurazione sul server per il loro passaggio diretto. Passarli attraverso la riga di comando è anche molto difficile per ottenere la fuga giusta. Due, più bastioni devono essere rimbalzati, rendendolo un po 'più complesso, specialmente quando non è chiaro dall'host di origine quale percorso prendere per un determinato host di destinazione. È più facile dire: "bounce-ssh bast1 bast2 nodeX - rm -rf /" che mantenere le rotte per una popolazione in evoluzione di host in una serie di file ssh-config.
Jayson,

Buona pesca !! Così meraviglioso e un po 'sporco !!
zw963,

2
Questo è orribile. Bravo. 👏
Pi Delport,

1
Questo è orribilmente fantastico, grazie! L'ho usato per un altro hack terribilmente bello ! :)
lumbric

1
bla="MyEnvSelection=dcop"
ssh user@host "export $bla && ./runProg"

Su bash ho provato con:

$ echo '#!/bin/sh' > readEnv.sh
$ echo 'echo "MyEnv: "$MyEnvFromSSH' >> readEnv.sh

$ scp readEnv.sh user@host:~/
$ bla="MyEnvFromSSH=qwert"
$ ssh user@host "export $bla && ./readEnv.sh"
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.