Джерело .profile та .bashrc для входу в ssh без tty


3

Як переконатися, що джерела ssh .profileта .bashrcвхід у систему без tty?

У мене є Mac (10.6.8), який я використовую для різних завдань UNIX-y, таких як розміщення сховищ git. У мене ввімкнено віддалений вхід через панель системних налаштувань "Спільний доступ". Коли я заходжуssh в машину, bashджерела ~/.profile, які я створив, щоб джерело свого ~/.bashrcфайлу та налаштував свій шлях до MacPorts . Проблема полягає в тому, що коли я бігаю sshбез такого tty, як це:

ssh myhost echo \$PATH

Або запустити gitкоманду, яка по суті використовує sshоднаковий спосіб:

git clone ssh://myhost/~/code/myrepo.git

Мій ~/.profileфайл ніколи не отримується, тому мій $PATHзмінний відсутній /opt/local(там, де встановлено MacPorts git). Я знаю, що:

  • Я можу налаштувати gitна своїй локальній машині використання /opt/local/bin/git-*на віддаленій машині
  • Я б не ця проблема , якщо я примушувати ttyзssh -t

Але я не хочу робити жодного з них. Я хочу, щоб мій віддалений апарат виводив мій ~/.profileфайл незалежно від того, я входив чи ні.

Як я втілю в життя цю мрію?

Також: Я перевірив поведінку на декількох машинах Linux (Debian і Fedora), і обидві системи, схоже, джерело ~/.bashrcфайлу при вході в систему, незалежно від того, чи є це tty. У мене склалося враження, що BSD та Linux використовують однакові реалізації OpenSSH та bash , тож здається, що різниця в поведінці може виникнути через відмінності у /etcконфігураційних файлах?

Відповіді:


2

Bash має спеціальні положення у своєму вихідному коді до джерела, ~/.bashrcколи його викликає rshdабо sshd. Це варіант компіляції, який, враховуючи ваш досвід, схоже, не вмикається під OSX.

Якщо ви входите в систему за допомогою ключа, ви можете (ab) використовувати command=опцію у ~/.ssh/authorized_keysфайлі. Ключ з commandопцією хороший лише для запуску зазначеної команди; але команда у authorized_keysфайлі працює зі змінною середовища, SSH_ORIGINAL_COMMANDвстановленою для вказаної користувачем команди (порожня для інтерактивних сесій). Отже, ви можете використовувати щось подібне в цьому ~/.ssh/authorized_keys(звичайно, це не застосовуватиметься, якщо ви не використовуєте цей ключ для автентифікації):

command=". ~/.profile;
         if [ -n \"$SSH_ORIGINAL_COMMAND\" ]; then
           eval \"$SSH_ORIGINAL_COMMAND\";
         else exec \"$SHELL\"; fi" ssh-rsa …

Зауважте, що я ставлю перерви рядка вище для розбірливості, але це насправді повинно бути все на одному рядку.

Як я можу встановити змінні середовища для віддаленого процесу rsync? можуть бути інші корисні пропозиції.


Я буду вдячний вам за відповідь на це, оскільки це було у запитанні, на яке ви посилалися, але я в кінцевому підсумку використовую ~ / .ssh / environment для встановлення шляху (жорсткий, на жаль). Це працює з / п. Я єдиний користувач, якому потрібна ця функціональність.
aaronstacy

Я спробував додати цей командний рядок до санкціонованих_кіїв на хості, але виявив, що в цьому випадку ключ більше не розпізнається і мені потрібно ввести пароль. Чи потрібно його додавати десь ще?
highsciguy

@highsciguy Ви, мабуть, authorized_keysнеправильно позначили синтаксис файлу або додали додатковий символ у рядку чи щось. Зокрема, переконайтесь, що ваш редактор не розділив рядок через обгортання слова.
Жиль

@aaronstacy Ознайомтеся з моєю відповіддю щодо способу використання ~ / .ssh / environment та не жорсткого коду шляху.
Клейтон Стенлі

6

Ось метод мати bash source .bashrc на неінтерактивних сесіях, щоб вам не довелося жорстко змінювати змінні середовища в декількох місцях:

  1. Набір PermitUserEnvironmentдля yesв /etc/sshd_config( людина SSHD )
  2. Набір BASH_ENVдля ~/.bashrcв ~/.ssh/environment( людина Баш )
  3. Додайте цей рядок у верхню частину ваших ~/.bashrcджерел /etc/profileдля джерел неінтерактивних сеансів:

Це по суті дублює інтерактивне середовище входу для неінтерактивних входів, без необхідності жорстких значень середовища коду (наприклад, $ PATH) у кількох місцях.

if [[ ! $- == *i* ]]; then
        . /etc/profile
fi

Крок 3. потрібен лише у тому випадку, якщо у вас встановлені шляхи Macports, /etc/pathsяк я. Але якщо ви встановлюєте ці шляхи (наприклад, /opt/local/bin) в ~/.bashrc, я думаю, вам не знадобиться крок 3.

Для вашої ситуації, ви повинні бути в змозі змінити ~/.bashrcдо ~/.profile.

У мене є ~/.bash_profileджерело ~/.bashrc, і я не використовую ~/.profile. З цією конфігурацією (та вищезазначеними змінами) змінні середовища bash (наприклад, $PATH) повинні виглядати ідентичними для інтерактивного входу, інтерактивного невходу в систему та неінтерактивних сесій.


Якщо ви використовуєте BASH_ENV, встановіть його ~/.profileта визначте там змінні середовища. Резервуйте .bashrcдля інтерактивних налаштувань (псевдоніми, завершення,…). Дивіться альтернативу .bashrc
Жиль

1
Це особисті переваги. Я вважаю за краще, щоб всі змінні середовища узгоджувались для різних типів сеансів, і менше підтримувати, коли всі ці змінні визначаються в одному файлі (тобто ~ / .bashrc).
Клейтон Стенлі

@ClaytonStanley дякую за відповідь! минуло певний час, як я заплутався з цим, але якщо мені доведеться повернутися до нього і використовувати вашу техніку, я можу врешті-решт змінити вашу відповідь на прийняту. ура!
aaronstacy

3

це дуже дратувало відменюйте цей рядок у config-top.h та відновіть:

/ * Визначте це, якщо ви хочете bash, щоб спробувати перевірити, чи він працює за допомогою sshd, і вивести джерело .bashrc, якщо так (наприклад, поведінка rshd). Це перевіряє наявність SSH_CLIENT або SSH2_CLIENT у початковому середовищі, яке можна обдурити за певних нечастих обставин. * /

визначити SSH_SOURCE_BASHRC

згідно ЗМІН у джерелі така поведінка була змінена в bash-2.05a-rc1. але поточна сторінка досі вимагає попередньої поведінки:

   Bash attempts to determine when it is being run with its standard input
   connected  to a a network connection, as if by the remote shell daemon,
   usually rshd, or the secure shell daemon sshd.  If bash  determines  it
   is  being  run  in  this  fashion,  it reads and executes commands from
   ~/.bashrc, if that file exists and is readable.  It will not do this if
   invoked as sh.  The --norc option may be used to inhibit this behavior,
   and the --rcfile option may be used to force another file to  be  read,
   but  rshd  does  not  generally  invoke the shell with those options or
   allow them to be specified.
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.