Dlaczego komenda zdalna SSH otrzymuje mniej zmiennych środowiskowych niż wtedy, gdy jest uruchamiana ręcznie? [Zamknięte]

Mam polecenie, które działa poprawnie, jeśli ssh na maszynie i uruchomię go, ale kończy się niepowodzeniem, gdy próbuję uruchomić go za pomocą zdalnego polecenia ssh, takiego jak:

ssh user@IP <command>

Porównywanie danych wyjściowych „env” przy użyciu obu metod rozpoczyna się w różnych środowiskach. Kiedy ręcznie loguję się do komputera i uruchamiam env, otrzymuję znacznie więcej zmiennych środowiskowych niż wtedy, gdy uruchamiam:

ssh user@IP "env"

Masz pomysł, dlaczego?

Istnieją różne rodzaje muszli. Powłoka wykonania polecenia SSH jest powłoką nieinteraktywną, podczas gdy normalna powłoka jest powłoką logowania lub powłoką interaktywną. Opis pochodzi z man bash:

       Powłoka logowania to taka, której pierwszy znak argumentu
       zero jest - lub zaczyna się od opcji --login.

       Powłoka interaktywna to taka, która została uruchomiona bez opcji
       argumenty i bez opcji -c, której standardowe wejście
       i błąd są podłączone do zacisków (jak określono
       przez isatty (3)) lub taki, który zaczął się od opcji -i. PS1 jest
       set i $ - obejmuje i, jeśli bash jest interaktywny, pozwalając na
       skrypt powłoki lub plik startowy, aby przetestować ten stan.

       Poniższe akapity opisują, w jaki sposób bash wykonuje swoje
       pliki startowe. Jeśli któryś z plików istnieje, ale nie może być
       czytaj, bash zgłasza błąd. Tyldy są rozwijane w pliku
       nazwy jak opisano poniżej w części Rozbudowa tyldy w
       Sekcja ROZSZERZENIE.

       Gdy bash zostanie wywołany jako interaktywna powłoka logowania lub jako
       najpierw nieinteraktywna powłoka z opcją --login
       czyta i wykonuje polecenia z pliku / etc / profile, jeśli
       ten plik istnieje. Po przeczytaniu tego pliku szuka
       ~ / .bash_profile, ~ / .bash_login i ~ / .profile, w tym
       porządek oraz odczytuje i wykonuje polecenia z pierwszego
       który istnieje i jest czytelny. Opcja --noprofile może
       być używane, gdy powłoka jest uruchamiana w celu zahamowania tego zachowania
       ior.

       Po wyjściu z powłoki logowania bash czyta i wykonuje polecenia
       z pliku ~ / .bash_logout, jeśli istnieje.

       Gdy jest to powłoka interaktywna, która nie jest powłoką logowania
       uruchomione, bash czyta i wykonuje polecenia z ~ / .bashrc,
       jeśli ten plik istnieje. Można to zahamować za pomocą
       --norc opcja. Opcja pliku --rcfile wymusi bash
       do czytania i wykonywania poleceń z pliku zamiast
       ~ / .bashrc.

       Gdy bash jest uruchamiany nieinteraktywnie, aby uruchomić powłokę
       skrypt na przykład szuka zmiennej BASH_ENV w
       środowisko rozszerza swoją wartość, jeśli się tam pojawia,
       i używa rozszerzonej wartości jako nazwy pliku do odczytu
       i wykonać. Bash zachowuje się tak, jakby następujące polecenie
       zostały wykonane:
              jeśli [-n "$ BASH_ENV"]; następnie . „$ BASH_ENV”; fi
       ale wartość zmiennej PATH nie jest używana do wyszukiwania
       dla nazwy pliku.

Co powiesz na pozyskanie profilu przed uruchomieniem polecenia?

ssh user@host "source /etc/profile; /path/script.sh"

Może się okazać, że najlepiej to zmienić, aby ~/.bash_profile, ~/.bashrcczy cokolwiek innego.

(Jak tutaj (linuxquestions.org) )

Środowisko powłoki nie ładuje się podczas uruchamiania zdalnego polecenia ssh. Możesz edytować plik środowiska ssh:

vi ~/.ssh/environment

Jego format to:

VAR1=VALUE1
VAR2=VALUE2

Sprawdź także sshdkonfigurację PermitUserEnvironment=yesopcji.

Miałem podobny problem, ale w końcu dowiedziałem się, że ~ / .bashrc było wszystkim, czego potrzebowałem.

Jednak w Ubuntu musiałem skomentować linię, która przestaje przetwarzać ~ / .bashrc:

#If not running interactively, don't do anything
[ -z "$PS1" ] && return

Odkryłem, że łatwym rozwiązaniem tego problemu było dodanie źródła / etc / profile na górze pliku script.sh, który próbowałem uruchomić w systemie docelowym. W systemach tutaj spowodowało to, że zmienne środowiskowe potrzebne skryptowi.sh zostały skonfigurowane tak, jakby działały z powłoki logowania.

W jednej z wcześniejszych odpowiedzi zasugerowano użycie ~ / .bashr_profile itp ... Nie spędziłem dużo czasu na tym, ale problem polega na tym, że ssh do innego użytkownika w systemie docelowym niż powłoka w systemie źródłowym, z którego się logujesz, wydaje mi się, że powoduje to użytkownika systemu źródłowego nazwa używana dla ~.

Po prostu wyeksportuj zmienne środowiskowe, które chcesz powyżej sprawdzania nieinteraktywnej powłoki w ~ / .bashrc.