Nieinteraktywne sesje ssh nie mają ustawionej PATH w niektórych systemach


3

Ustawiłem swoje środowisko .profile. Mój .profilejest idempotent i .bash_profile, .bashrc, .kshrca .zshrcwszystkie źródła .profile. W ten sposób zawsze otrzymuję to samo środowisko, niezależnie od tego, z której powłoki korzystam, i czy niezależnie od tego, czy jest to powłoka interaktywna czy powłoka logowania.

Działa to również w przypadku ssh(1)użycia nieinteraktywnego , chociaż nie jestem pewien, dlaczego.

iridium:aram$ ssh sunos.mgk.ro 'env|grep ^PATH'
PATH=.:/home/aram/bin:/home/aram/bin/sunos:/home/aram/bin/sunos/amd64:/home/aram/bin/sunos/386:/home/aram/go/bin:/opt/local/bin:/opt/local/sbin:/usr/gnu/bin:/usr/bin:/sbin:/usr/sbin:/usr/sfw/bin:/usr/local/bin:/usr/local/sbin:/home/aram/plan9/bin
iridium:aram$ ssh iridium 'env|grep ^PATH'
PATH=.:/Users/aram/bin:/Users/aram/bin/darwin:/Users/aram/bin/darwin/amd64:/Users/aram/bin/darwin/386:/Users/aram/go/bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/pkg/bin:/usr/pkg/sbin:/usr/local/plan9/bin
iridium:aram$ ssh crimson 'env|grep ^PATH'
PATH=.:/home/aram/bin:/home/aram/bin/linux:/home/aram/bin/linux/amd64:/home/aram/bin/linux/386:/bin:/usr/bin:/sbin:/usr/sbin:/usr/games:/usr/local/bin:/usr/local/sbin

Jednak w przypadku większości systemów to nie działa.

iridium:aram$ ssh ci20 'env|grep ^PATH'
PATH=/usr/bin:/bin

Próbowałem sprawić, by to zadziałało, ale bez powodzenia. Próbowałem:

  • przełącz się na inną powłokę zamiast bash
  • wyłącz PAM w sshd_config
  • z włączoną funkcją PAM ustaw BASH_ENV w / etc / environment

Nie przyniosły żadnego efektu, wygląda na to, że / etc / environment nie jest w ogóle odczytywany, niezależnie od ustawienia PAM.

Proszę nie sugerować, że powinienem wymusić na bashu interakcję w moim wywołaniu ssh, lub że powinienem ręcznie wyodrębnić środowisko w moim wywołaniu ssh, staram się tutaj rozwiązać podstawowy problem.

Próbując rozwiązać ten problem, nauczyłem się kilku rzeczy na temat bash. Wygląda na to, że bash zawsze będzie źródłem bashrc, nawet jeśli jest to powłoka nieinteraktywna, jeśli standardowym wejściem jest gniazdo. Niektóre wersje OpenSSH zaczynają bash w ten sposób, ale w innych wersjach standardowym wejściem jest potok. W bash znajduje się również kod, który próbuje wykryć, czy został uruchomiony w sesji ssh, i w takim przypadku będzie także pobierał bashrc niezależnie od statusu interaktywnego, ale w niektórych przypadkach kod ten jest wyłączany w czasie kompilacji. Fakty te wydają się związane z moim problemem, ale nie jest jasne, jak mogę rozwiązać mój problem.

Odpowiedzi:


3

W pełni zrozumiałem na czym polega problem.

Sshd powinien naprawdę wykonać nieinteraktywną sesję logowania zamiast nieinteraktywnej sesji bez logowania, ale tak nie jest. Bash bardzo stara się wykryć użycie ssh, a źródła bashrc, jeśli sądzi, że zostało uruchomione przez sshd, bez względu na to, czy jest to interaktywne czy zalogowane. Tylko bash to robi. Ponieważ używam bash, polegałem na tym zachowaniu pozyskiwania, nawet jeśli nie działało to z innymi powłokami.

Istnieją dwa sposoby wykrywania ssh. Sprawdza, czy stdin jest gniazdem (1), a jeśli to się nie powiedzie, szuka pewnych zmiennych SSH_ (2). Niedawno openssh zmienił sposób, w jaki działa, więc (1) już nigdy nie będzie działać, ponieważ stdin jest teraz potokiem, a nie gniazdem. (2) jest włączony w niektórych dystrybucjach Linuksa, ale wyłączony w innych. Korzystałem z dystrybucji, w których została włączona.

Ponieważ nie było co bash okropny, a ponieważ to nie działa niezawodnie i tak, jestem teraz ustawienie BASH_ENV w ~ / .ssh / środowiska, tak że teraz zawsze działa, ale niestety mam teraz ustawić PermitUserEnvironment yesw sshd_config...

Nie jest też jasne, dlaczego nie mogę go ustawić /etc/environment, więc działa dla wszystkich użytkowników.

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.