Jak mogę przekazać zmienną środowiskową za pomocą polecenia ssh? [duplikować]


42

Jak mogę przekazać wartość do polecenia ssh, tak aby środowisko uruchomione na komputerze hosta zaczynało się od określonej zmiennej środowiskowej wybranej przeze mnie?

EDYCJA: Celem jest przekazanie bieżącego pulpitu kde (z dcop kwin KWinInterface currentDesktop) do nowej powłoki utworzonej, aby móc przekazać lokalizacje nfs do mojej instancji JEdit na oryginalnym serwerze, która jest unikalna dla każdego pulpitu KDE. (Korzystanie z mechanizmu takiego jak emacsserver / emacsclient )

Powodem, dla którego wiele instancji ssh może być w locie, jest to, że kiedy konfiguruję swoje środowisko, otwieram kilka różnych instancji ssh na różnych maszynach.

Odpowiedzi:


16

~/.ssh/environmentPlik może być używany do ustawiania zmienne mają być dostępne dla zdalnych poleceń. Musisz włączyć PermitUserEnvironmentw konfiguracji sshd.

Zmienne ustawione w ten sposób są eksportowane do procesów potomnych, dzięki czemu można:

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

a myscript będzie wiedział, że Foo to Bar, a Joe ma 37 lat.


3
zmienna musi potencjalnie zmienić każde połączenie ssh
Ross Rogers

1
Może lepiej opisać, co próbujesz zrobić i dlaczego. Mogą być inne rozwiązania. Plik środowiska musiałby być generowany dynamicznie przy każdym wywołaniu ssh, co nie jest niemożliwe.
EmmEff

Co się zmieni? Wartości tych zmiennych, a nawet ich nazw?
innaM

cerować. Wypróbowałem to rozwiązanie, ale nie mam dostępu do pliku konfiguracyjnego sshd i umieszczenie varsa w ~ / .ssh / environment lub ~ / .ssh2 / environment nie działa. Chyba użyję kludge, w którym zostawiam tę zmienną na dysku nfs, a następnie łączę ją z moim plikiem instalacyjnym ~ / .tcsh.
Ross Rogers

2
Ta odpowiedź nie wydaje się odpowiadać na pytanie.
intuicyjnie,

51

SendEnvOpcja jest Twój facet.

~ / .ssh / config: (lokalnie)

SendEnv MYVAR

/ etc / ssh / sshd_config: (na zdalnym końcu)

AcceptEnv MYVAR

Teraz, bez względu na wartość $MYVARlokalnie, staje się ona dostępna również w sesji zdalnej.
Jeśli zalogujesz się wiele razy, każda sesja będzie miała własną kopię $MYVARz możliwie różnymi wartościami.

~/.ssh/environmentjest przeznaczony do innych celów. To działa jak $ENVplik podczas zdalnego wykonywania poleceń innych niż powłoki .


5
można również przekazać (bardziej użytecznie) przez wiersz poleceń jako ssh myserver -o SendEnv="MYVAR", aby można było uczynić go dynamicznym w skryptach.
Mike Campbell

29

Jest też okropny, okropny hack.

Jeśli twój skrypt zużywa zmienną na odległym końcu (tzn. Możesz nazwać ją jak chcesz), możesz nadużyć zmiennych regionalnych. Każda zmienna w postaci LC_ * będzie przekazywana dosłownie, bez konieczności jakiejkolwiek konfiguracji.

Na przykład mamy serię serwerów bastionowych u jednego z moich klientów. Nienawidzę konieczności łączenia się z nim, aby połączyć się z innym serwerem ... i innym serwerem ... za każdym razem. Mam skrypt, który zachowuje się jak SSH, tyle że jest sprytny.

Zasadniczo, jeśli ustawiony jest LC_BOUNCE_HOSTS, dzieli go na spacje i usuwa pierwszy host. Następnie odbija się i uruchamia ten sam skrypt. W węźle docelowym ta lista jest ostatecznie pusta, więc uruchamia polecenie. Mam również tryb debugowania (który jest świetny podczas problemów z siecią), który jest ustawiany przez LC_BOUNCE_DEBUG. Ponieważ ssh przekazuje mi to wszystko magicznie, nie muszę robić nic poza rozpoznawaniem końca listy hostów (co robię z opcją -).

Czuję się brudny za każdym razem, gdy go używam, ale działa wszędzie, gdzie go wypróbowałem.


2
Dlaczego miałbyś używać czegoś takiego zamiast wbudowanej ProxyCommandopcji OpenSSH ? Edytuj swój ~/.ssh/configi dodaj blok podobny Host *.example.com: ProxyCommand -ssh -W %h:%p bastionhosti pozwól mu tunelować twoje połączenia dla Ciebie.
Kirk Strauser,

1
W przypadku tuneli nie jest tak źle. W przypadku środowisk env istnieją dwa powody: po pierwsze, PermitUserEnvironment wymaga dostępu administratora do konfiguracji na serwerze, aby przekazywać je bezpośrednio. Przekazanie ich przez linię poleceń jest również bardzo trudne do prawidłowego ucieczki. Dwa, wiele bastionów musi zostać odrzuconych, co czyni to nieco bardziej złożonym - szczególnie, gdy z hosta źródłowego nie jest jasne, którą ścieżkę wybrać do określonego hosta docelowego. Łatwiej powiedzieć: „bounce-ssh bast1 bast2 nodeX - rm -rf /” niż utrzymywać trasy ewoluującej populacji hostów w szeregu plików ssh-config.
Jayson

Dobry chwyt !! Tak cudownie i trochę brudno !!
zw963

2
To jest okropne. Brawo. 👏
Pi

1
To jest okropnie świetne, dzięki! Użyłem go do jeszcze jednego niesamowicie miłego włamania ! :)
lędźwiowy

28

Możesz przekazać wartości za pomocą polecenia podobnego do następującego:

ssh username@machine VAR=value cmd cmdargs

Możesz przetestować za pomocą:

ssh machine VAR=hello env

Na tcsh wydaje się, że działają:

ssh machine "setenv VAR <value>; printenv"

Wygląda na to, że działa dobrze w środowiskach bash. Szkoda, że ​​jestem w korporacyjnym środowisku tcsh.
Ross Rogers

2
Jak mogę korzystać z sesji interaktywnie?
luckydonald

1
Zauważ, że pierwszy przykład działa tylko dla pierwszego polecenia, jeśli łączysz polecenia razem (z &&). W export VAR=value;tym przypadku działa bash zamiast setenv w trzeciej formie.
contrebis

2
To właśnie skończyłem! Gdziekolwiek się wybierasz, zabierz ze sobą swoje środowisko. Twój może zrobić to tak: ssh user@host "$(<env_to_source.sh) command ..." . W env do source mam export var=value ; na osobnych wierszach (pamiętaj średnik).
Tomasz Gandor

@TomaszGandor: lata później, wciąż doskonały - pozwala mi nawet przekazywać skomplikowane rzeczy, takie jak PROMPT_COMMAND tam, bez konieczności martwienia się o ucieczkę :-) 1000 dzięki.
Czerwona pigułka

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

Na bash testowałem z:

$ 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"
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.