SSH - définir env vairables par chaque connexion - hôte partagé godaddy

Mon problème est que je dois définir des variables env (comme GIT_EXEC_PATH) sur un serveur. J'ai besoin de ces variables à chaque connexion (donc par bash et par des commandes à distance non plus). J'ai réussi à définir ces variables par bash avec .bash_profile, mais j'ai des problèmes avec les commandes à distance. J'ai trouvé qu'il était possible d'écrire des commandes dans ~ / .ssh / authorized_keys avant la clé rsa réelle, mais je ne veux pas y écrire toujours, j'ai besoin d'une solution permanente ... J'ai trouvé que le ~ / .ssh Le fichier / rc est exécuté par chaque connexion ssh, donc j'ai mis mes déclarations de variables env, mais cela n'a pas fonctionné. Les variables sont définies dans le fichier rc, mais après cela, elles ont disparu. : S Peut-être que le fichier rc s'exécute dans un sous-shell: S Y a-t-il un moyen de définir ces variables dans bash et dans les commandes à distance sans duplication de code?

Éditer:

J'ai édité la question, car le serveur est un hôte partagé godaddy, il a donc une configuration unique. Les fichiers / etc / ssh / sshd_config et / etc / ssh / ssh_config sont vides. Il y a des commentaires dans ces fichiers, si vous êtes curieux, je peux les copier ici.

1. Le ~ / .bash_profile provient (par les connexions bash uniquement),
2. le ~ / .bashrc n'est jamais sourcé,
3. le ~ / .profile n'est jamais sourcé,
4. l'environnement ~ / .ssh / n'est jamais sourcé,
5. le ~ / .ssh / rc est originaire (par bash et remote both), mais je pense qu'il est appelé en sous-shell, car les variables disparaissent.
6. Le ~ / .ssh / authorized_keys provient de chaque fois, mais je dois écrire les commandes avant chaque clé rsa (donc je ne veux pas configurer avec ça).

Résumé:

Je peux bien configurer le bash (avec .bash_profile), mais je ne peux pas configurer les appels distants. C'est le problème. Je recherche un fichier provenant à la fois de commandes bash et distantes.

Par exemple:

La commande git-upload-pack trouve le fichier exe, car la variable env GIT_EXEC_PATH est définie, mais avec remote: "git clone [email protected]: myrepo local / myrepo" le serveur ne trouve pas cette commande, car GIT_EXEC_PATH n'est pas défini.

Edit2:

Selon cela , et mes journaux printenv: le ~ / .ssh / rc fonctionne en shell normal, pas en sous-shell, c'est donc une énigme pour laquelle les variables env ne collent pas ...

J'ai créé un exécutable: ~ / logenv :

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

Et mettez ceci dans le ~ / .ssh / rc :

export AAA=teszt
source ~/logenv

Par bash login & "source logenv" le résultat était:

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

Par "ssh [email protected] 'exec ~ / logenv'" distant, le résultat était:

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

Le fichier rc provient donc, mais après cela, les variables disparaissent ...: S

En supposant que vous ayez UsePAM yesdans /etc/ssh/sshd_configet en supposant que vous vouliez que ces variables d'environnement soient définies pour chaque utilisateur, vous pouvez avoir des variables d'environnement définies par pam pour vous. Si vous avez défini les variables d'environnement, /etc/gitenvvous pouvez ajouter cette ligne à/etc/pam.d/sshd

auth required pam_env.so envfile=/etc/gitenv

Ou en inspectant ce fichier, vous pourriez constater qu'il y a déjà un pam_env.so utilisé, et déjà un fichier auquel vous pouvez ajouter des éléments. Soyez juste prudent et assurez-vous d'avoir soigneusement testé vos modifications avant de terminer votre session ssh, car lorsque vous jouez avec pam, vous pouvez complètement rompre votre capacité à vous connecter à votre serveur, si vous ne faites pas attention.

Je mets une variable d'environnement pour mes connexions SSH en utilisant le ~/.ssh/environment. Le fichier peut contenir des variables dans le formulaire VAR=value, pas besoin de les exporter explicitement.

Cependant, ce fichier de configuration utilisateur est ignoré par défaut par le processus du serveur SSH, sauf si l'option PermitUserEnvironment est définie sur yes. Par conséquent, vous devez vous assurer de modifier / etc / sshd_config sur le serveur SSH pour ajouter ou mettre à jour ce paramètre:

PermitUserEnvironment yes

Vous devez recharger la configuration du serveur SSH. Sur RHEL ou Suse Linux, vous le faites (en tant que root)

/sbin/service sshd reload

(Remplacer éventuellement sshd par ssh si cela ne fonctionne pas)

Sur Ubuntu (en utilisant upstart) vous faites

sudo reload ssh

Sur tout autre Linux, vous pouvez essayer (en tant que root)

/etc/init.d/sshd reload

(Remplacez sshd par ssh ou openssh ou tout ce qui correspondrait au script d'initialisation du serveur SSH)

Je n'ai plus d'hôte partagé godaddy, je ne peux donc pas vérifier si les solutions proposées sont valides. Cela restera la réponse acceptée, car cela a fonctionné par moi lorsque j'ai posé la question. Les autres réponses pourraient également fonctionner. Je laisse la communauté décider avec des votes positifs.

D'accord. La solution est qu'il n'y a pas de solution sur un hôte partagé godaddy. J'ai tout essayé, mais rien ne fonctionne, j'ai donc décidé de rester avec les ~ / .ssh / authorized_keys:

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

Dans le ~ / 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;

Et dans le ~ / .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

Je dois donc copier la commande = "..." sur chaque clé rsa dans les authorized_keys. Il s'agit de duplication de code, mais je ne pense pas qu'il existe une autre solution sur un hôte partagé godaddy.

Si vous utilisez bashcomme shell, essayez d'ajouter les paramètres d'environnement à .bashrc.

Vérifiez d'abord que cela s'exécute lors de la connexion, ce n'est peut-être pas le cas, car les fichiers standard ont souvent quelque chose comme:

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

au début d'eux. toute modification que vous souhaitez apporter même pour des connexions non interactives devra aller au-dessus d'une telle déclaration.

.profileest un endroit plus général pour placer une configuration comme celle-ci et est respecté par la plupart des shells (sur une configuration Debian par défaut, c'est ce ~/.profilequi appelle ~/.bashrcen premier lieu). Vous devrez peut-être être plus prudent lors de l'édition .profileau cas où il serait interprété par d'autres shells - c'est-à-dire, essayez d'éviter d'utiliser bashdes extensions spécifiques.

Éditer

Si vous avez une .bash_profilemodification qui au lieu de .profile: bash l'utilisera en faveur du fichier plus général, et vous pouvez utiliser en toute sécurité des choses spécifiques à bash.

Vous pouvez utiliser la commande pour tous les utilisateurs / clé sans ajouter la partie commande dans les clés autorisées en ajoutant cette ligne au fichier sshd_config:

ForceCommand ~/connect.sh

Dans ce cas, je vous suggère d'utiliser un chemin absolu pour le script

Je vous propose une autre approche.

Vous configurez un fichier avec la déclaration de votre variable d'environnement, puis vous le sourcez chaque fois que vous appelez une commande à distance.

Exemple: vous mettez les variables nécessaires dans ~ / .my_var.rc puis pour chaque commande à distance que vous effectuez ssh user@remote bash -c "source ~/.my_var.rc; <your command>"

Si cela vous convient, vous pouvez ensuite affiner ce concept et l'écrire pour plus de commodité. Si vous en avez besoin uniquement pour les commandes git, je créerais un script git.sh qui ferait ceci:

#!/bin/bash

source ~/.my_var.rc

git $@

En supposant que ce script se trouve dans votre répertoire personnel, vous l'appelleriez: ssh user@remote git.sh pull origin master

Remarque: c'est un simple point de départ. Par exemple, il ne prend pas en charge les paramètres avec des espaces.

Cela ne répond pas à la question générale sur PATHS, mais cela vous permet d'utiliser un référentiel git sur un serveur distant qui n'a pas git sur son chemin et auquel vous n'avez pas accès root. Cette solution vient de cette page .

git clone -u relative/path/to/bin/git-upload-pack [email protected]:relative/path/to/remote_repository.git

Pour pousser et récupérer également:

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 / profile proviendra de chaque connexion avec ssh-client.