SSH - встановлює env-перекладні при кожному з'єднанні - godaddy shared host

Моя проблема полягає в тому, що мені потрібно встановити змінні env (наприклад, GIT_EXEC_PATH) на сервері. Мені потрібні ці змінні при кожному з'єднанні (так само через bash та віддалені команди). Мені вдалося встановити ці змінні bash за допомогою .bash_profile, але у мене проблеми з віддаленими командами. Я виявив, що можна писати команди в ~ / .ssh / pooblasti_keys перед фактичним ключем rsa, але я не хочу писати там завжди, мені потрібно постійне рішення ... Я виявив, що ~ / .ssh / rc-файл виконується кожним sh-логіном, тому я розміщую там свої env-змінні, але це не працює. Змінні встановлюються у файлі rc, але після цього вони зникали. : S Можливо, файл rc працює в підзарядці: S Чи є спосіб визначити ці змінні в bash та віддалених командах без дублювання коду?

Редагувати:

Я відредагував це питання, оскільки сервер - це спільний хост, і він має унікальну конфігурацію. Файли / etc / ssh / sshd_config та / etc / ssh / ssh_config файли порожні. У цих файлах є коментарі, якщо вам цікаво, я можу скопіювати його сюди.

1. Програма ~ / .bash_profile створена (лише за допомогою bash-з'єднань),
2. ~ / .bashrc ніколи не отримується,
3. ~ / .profile ніколи не отримується,
4. середовище ~ / .ssh / ніколи не створюється,
5. ~ / .ssh / rc є джерелом (за допомогою bash та віддалених обох), але я думаю, це називається в нижній частині, тому що змінні зникають.
6. ~ / .Ssh / pooblasti_keys надходить щоразу, але я повинен писати команди перед кожною клавішею rsa (тому я не хочу налаштовувати її).

Підсумок:

Я можу налаштувати bash добре (за допомогою .bash_profile), але не можу налаштувати віддалені дзвінки. У цьому проблема. Я шукаю файл, який базується як на bash, так і на віддалені команди.

Наприклад:

Команда git-upload-pack знаходить файл exe, оскільки змінна GV_EXEC_PATH env встановлена, але з віддаленим: "git clone user@domain.com: myrepo local / myrepo" сервер не знаходить цієї команди, оскільки GIT_EXEC_PATH не встановлено.

Edit2:

Відповідно до цього , і мій журнал printenv: ~ / .ssh / rc працює в звичайній оболонці, а не в нижній частині, тому це загадка, чому змінні env не прилипають ...

Я створив виконуваний файл: ~ / logenv :

echo "" >> mylog.txt
date >> mylog.txt
printenv >> mylog.txt
echo "" >> mylog.txt

І помістіть це в ~ / .ssh / rc :

export AAA=teszt
source ~/logenv

По bash login & "source logenv" результат був:

Tue May 15 04:21:37 MST 2012
TERM=cygwin
SHELL=/bin/bash
SSH_CLIENT=censored
SSH_TTY=/dev/pts/2
USER=myuser
AAA=teszt
MAIL=/var/mail/myuser
PATH=/usr/local/bin:/bin:/usr/bin
PWD=/home/content/65/7962465
SHLVL=3
HOME=/var/chroot/home/content/65/7962465
LOGNAME=myuser
SSH_CONNECTION=censored
_=/usr/bin/printenv

Tue May 15 04:21:41 MST 2012
HOSTNAME=censored
TERM=cygwin
SHELL=/bin/bash
HISTSIZE=1000
SSH_CLIENT=censored

У віддаленому "ssh myuser@domain.com 'exec ~ / logenv'" результат був:

Tue May 15 04:25:52 MST 2012
SHELL=/bin/bash
SSH_CLIENT=censored
USER=myuser
AAA=teszt
MAIL=/var/mail/myuser
PATH=/usr/local/bin:/bin:/usr/bin
PWD=/home/content/65/7962465
SHLVL=3
HOME=/var/chroot/home/content/65/7962465
LOGNAME=myuser
SSH_CONNECTION=censored
_=/usr/bin/printenv

Tue May 15 04:25:52 MST 2012
SHELL=/bin/bash
SSH_CLIENT=censored
USER=myuser
PATH=/usr/local/bin:/bin:/usr/bin
MAIL=/var/mail/myuser
PWD=/home/content/65/7962465
HOME=/var/chroot/home/content/65/7962465

Таким чином, rc-файл розміщений, але після цього змінні невтішні ...: S

Якщо у вас є UsePAM yesв /etc/ssh/sshd_config, і якщо ви хочете , щоб ці змінні оточення , встановлені для кожного користувача, ви можете мати змінні Пей набір середу для вас. Якщо у вас визначені змінні середовища, /etc/gitenvви можете додати цей рядок до/etc/pam.d/sshd

auth required pam_env.so envfile=/etc/gitenv

Або вставляючи цей файл, ви можете виявити, що вже використовується pam_env.so, і вже файл, до якого ви можете додати речі. Будьте обережні і переконайтесь, що ви ретельно перевірили свої зміни, перш ніж закінчити сеанс ssh, оскільки, коли ви псуєтеся з пам’яткою, ви можете повністю порушити свою здатність увійти до свого сервера, якщо ви не будете обережні.

Я встановлюю змінну середовища для моїх SSH-з'єднань за допомогою ~/.ssh/environment. Файл може містити змінні форми VAR=value, не потрібно їх явно експортувати.

Однак цей файл конфігурації користувача за замовчуванням ігнорується процесом SSH-сервера, якщо для параметра PermitUserEnvironment не встановлено значення "Так". Тому вам потрібно обов’язково відредагувати / etc / sshd_config на сервері SSH, щоб додати або оновити цей параметр:

PermitUserEnvironment yes

Вам потрібно перезавантажити конфігурацію сервера SSH. На RHEL або Suse Linux ви робите (як root)

/sbin/service sshd reload

(Можливо, замініть sshd на ssh, якщо він не працює)

У Ubuntu (за допомогою запуску) ви робите

sudo reload ssh

На будь-якому іншому Linux ви можете спробувати (як root)

/etc/init.d/sshd reload

(Замініть sshd на ssh або openssh або будь-що інше, що відповідатиме сценарію init SSH-сервера)

У мене більше немає спільного хоста, тому я не можу перевірити, чи запропоновані рішення є дійсними. Це залишиться прийнятою відповіддю, оскільки вона працювала мною, коли я задавав питання. Інші відповіді можуть також працювати. Я дозволяю громаді вирішити це з нагородами.

В порядку. Рішення полягає в тому, що не існує рішення для спільного хазяїна. Я спробував усе, але нічого не виходить, тому вирішив залишитися з ~ / .ssh / pooblasti_keys:

command="~/connect.sh" ssh-rsa AAAAB3NzaC...

У ~ / connect.sh:

#!/bin/bash
if [ -f "${HOME}/.env_profile" ]; then
        source ~/.env_profile
fi;

if [ "x${SSH_ORIGINAL_COMMAND}x" == "xx" ]; then
        $SHELL --login
else
        eval "${SSH_ORIGINAL_COMMAND}"
fi;

І в ~ / .env_profile:

export PATH=$PATH:$HOME/bin:$HOME/git/libexec/git-core
export LD_LIBRARY_PATH=$HOME/git/lib
export GIT_EXEC_PATH=~/git/libexec/git-core
export GIT_TEMPLATE_DIR=~/git/share/git-core/templates

Тому я повинен скопіювати команду = "..." в кожен ключ rsa в авторизованих_кейдах. Це дублювання коду, але я не думаю, що існує ще одне рішення щодо спільних хостів.

Якщо ви використовуєте bashв якості оболонки, спробуйте додати налаштування середовища .bashrc.

Спершу переконайтеся, що це запускається при вході в систему, можливо, це не так, як у стандартних файлів часто є щось на кшталт:

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

на початку їх. будь-які зміни, які ви хочете внести навіть для неінтерактивних входів, повинні бути вище такого твердження.

.profileє більш загальним місцем для встановлення подібної конфігурації і її поважають більшість оболонок (для налаштування Debian за замовчуванням це ~/.profileвиклик ~/.bashrcв першу чергу). Вам може знадобитися більш ретельне редагування, .profileякщо воно коли-небудь інтерпретується іншими оболонками - тобто намагайтеся уникати використання bashконкретних розширень.

Редагувати

Якщо у вас є .bash_profileредагування, яке замість .profile: bash використовуватиме його на користь більш загального файла, і ви можете сміливо використовувати конкретні речі bash там.

Ви можете використовувати команду для всіх користувачів / клавіш, не додаючи командної частини до дозволених ключів, додавши цей рядок у файл sshd_config:

ForceCommand ~/connect.sh

У цьому випадку я пропоную вам використовувати абсолютний шлях для сценарію

Я пропоную вам інший підхід.

Ви налаштовуєте файл з декларацією змінної вашого середовища, а потім створюєте джерело кожного разу, коли ви викликаєте віддалену команду.

Приклад: ви ставите необхідні змінні в ~ / .my_var.rc, а потім для кожної віддаленої команди, яку ви виконуєте ssh user@remote bash -c "source ~/.my_var.rc; <your command>"

Якщо це вам підходить, ви можете вдосконалити цю концепцію та прописати її для зручності. Якщо вам це потрібно лише для команд git, я б створив сценарії git.sh, які б це зробили:

#!/bin/bash

source ~/.my_var.rc

git $@

Якщо припустити, що цей скрипт буде у вашому домашньому каталозі, ви називатимете його: ssh user@remote git.sh pull origin master

Примітка: це простий вихідний пункт. Наприклад, він не підтримує параметри з пробілами.

Це не дає відповіді на загальне запитання про PATHS, але це дозволяє використовувати репозиторій git на віддаленому сервері, який не має git на своєму шляху і до якого ви не маєте кореневого доступу. Це рішення походить з цієї сторінки .

git clone -u relative/path/to/bin/git-upload-pack username@host.com:relative/path/to/remote_repository.git

Щоб також натиснути і отримати:

git config remote.origin.receivepack relative/path/to/bin/git-receive-pack
git config remote.origin.uploadpack relative/path/to/bin/git-upload-pack

/ etc / профіль буде розміщений при кожному з'єднанні з ssh-клієнтом.