SSH - imposta i parametri env per ogni connessione - godaddy host condiviso

Il mio problema è che devo impostare le variabili env (come GIT_EXEC_PATH) su un server. Ho bisogno di quelle variabili per ogni connessione (quindi tramite bash e anche dai comandi remoti). Sono riuscito a impostare quelle variabili bash con .bash_profile, ma ho problemi con i comandi remoti. Ho scoperto che è possibile scrivere i comandi in ~ / .ssh / authorized_keys prima dell'effettiva chiave rsa, ma non voglio scrivere lì sempre, ho bisogno di una soluzione permanente ... Ho scoperto che ~ / .ssh Il file / rc viene eseguito da ogni login ssh, quindi ho inserito le dichiarazioni delle variabili env, ma non ha funzionato. Le variabili sono impostate nel file rc, ma successivamente sono scomparse. : S Forse il file rc viene eseguito in una subshell: S Esiste un modo per definire quelle variabili in bash e nei comandi remoti senza duplicazione del codice?

Modificare:

Ho modificato la domanda, perché il server è un host condiviso godaddy, quindi ha una configurazione unica. I file / etc / ssh / sshd_config e / etc / ssh / ssh_config sono vuoti. Ci sono commenti in questi file, se sei curioso posso copiarlo qui.

1. Il ~ / .bash_profile proviene (solo da connessioni bash),
2. ~ / .bashrc non proviene mai,
3. il ~ / .profile non viene mai fornito,
4. l'ambiente ~ / .ssh / non viene mai fornito,
5. ~ / .ssh / rc proviene da entrambi (bash e remote), ma penso che sia chiamato in subshell, perché le variabili scompaiono.
6. ~ / .Ssh / authorized_keys proviene ogni volta, ma devo scrivere i comandi prima di ogni chiave rsa (quindi non voglio configurarmi con quello).

Sommario:

Posso configurare bene il bash (con .bash_profile), ma non posso configurare le chiamate remote. Questo è il problema. Sto cercando un file che proviene da entrambi i comandi bash e remoti.

Per esempio:

Il comando git-upload-pack trova il file exe, perché la variabile env GIT_EXEC_PATH è impostata, ma con remote: "git clone user@domain.com: myrepo local / myrepo" il server non trova quel comando, perché GIT_EXEC_PATH non è impostato.

Edit2:

Secondo questo , e i miei log di printenv: ~ / .ssh / rc è in esecuzione nella shell normale, non nella subshell, quindi è un indovinello il motivo per cui le variabili env non si attaccano ...

Ho creato un eseguibile: ~ / logenv :

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

E mettilo in ~ / .ssh / rc :

export AAA=teszt
source ~/logenv

Con bash login & "source logenv" il risultato è stato:

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

Tramite "ssh myuser@domain.com 'exec ~ / logenv'" remoto il risultato era:

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

Quindi il file rc viene fornito, ma successivamente le variabili scompaiono ...: S

Supponendo di avere UsePAM yesin /etc/ssh/sshd_config, e supponendo che si desidera queste variabili di ambiente impostate per ogni utente, è possibile avere le variabili di ambiente set pam per voi. Se hai le variabili d'ambiente definite in /etc/gitenvpuoi aggiungere questa riga/etc/pam.d/sshd

auth required pam_env.so envfile=/etc/gitenv

O inserendo questo file, potresti scoprire che esiste già un pam_env.so in uso e già un file a cui puoi aggiungere elementi. Fai solo attenzione e assicurati di aver testato a fondo le modifiche prima di terminare la sessione ssh, poiché quando stai scherzando con pam, puoi interrompere completamente la tua capacità di accedere al tuo server, se non stai attento.

Sto impostando alcune variabili d'ambiente per le mie connessioni SSH usando il ~/.ssh/environment. Il file può contenere variabili nel modulo VAR=value, non è necessario esportarle esplicitamente.

Tuttavia, questo file di configurazione utente viene ignorato per impostazione predefinita dal processo del server SSH a meno che l'opzione PermitUserEnvironment sia impostata su yes. Pertanto è necessario assicurarsi di modificare / etc / sshd_config sul server SSH per aggiungere o aggiornare questo parametro:

PermitUserEnvironment yes

Devi ricaricare la configurazione del server SSH. Su RHEL o Suse Linux lo fai (come root)

/sbin/service sshd reload

(Possibilmente sostituire sshd con ssh se non funziona)

Su Ubuntu (usando upstart) lo fai

sudo reload ssh

Su qualsiasi altro Linux, potresti provare (come root)

/etc/init.d/sshd reload

(Sostituisci sshd con ssh o openssh o qualunque cosa corrisponda allo script init del server SSH)

Non ho più un host godaddy condiviso, quindi non posso verificare se le soluzioni proposte sono valide. Questo rimarrà la risposta accettata, poiché ha funzionato da me quando ho posto la domanda. Anche le altre risposte potrebbero funzionare. Ho lasciato che la comunità lo decidesse con voti positivi.

Ok. La soluzione è che non esiste una soluzione su un host condiviso godaddy. Ho provato di tutto, ma niente funziona, quindi ho deciso di rimanere con i ~ / .ssh / authorized_keys:

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

In ~ / 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;

E nel ~ / .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

Quindi devo copiare il comando = "..." su ogni chiave rsa in authorized_keys. Questa è la duplicazione del codice, ma non credo che ci sia un'altra soluzione su host godaddy condivisi.

Se si utilizza bashcome shell, provare ad aggiungere le impostazioni di ambiente a .bashrc.

Controlla prima che questo venga eseguito al momento dell'accesso, potrebbe non esserlo poiché i file standard hanno spesso qualcosa del tipo:

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

all'inizio di loro. qualsiasi modifica che si desidera apportare anche per accessi non interattivi dovrà andare oltre tale affermazione.

.profileè un posto più generale per mettere una configurazione come questa ed è rispettato dalla maggior parte delle shell (su una configurazione Debian predefinita è ~/.profileche chiama ~/.bashrcin primo luogo). Potrebbe essere necessario eseguire un'attenta modifica .profilenel caso in cui venga mai interpretato da altre shell, ovvero cercare di evitare l'uso di bashestensioni specifiche.

modificare

Se hai una .bash_profilemodifica che invece di .profile: bash la userà a favore del file più generale, e puoi tranquillamente usare cose specifiche di bash lì dentro.

È possibile utilizzare il comando per tutti gli utenti / la chiave senza aggiungere la parte di comando in authorized_keys aggiungendo questa riga al file sshd_config:

ForceCommand ~/connect.sh

In questo caso ti suggerisco di utilizzare un percorso assoluto per lo script

Ti sto proponendo un altro approccio.

Si configura un file con la dichiarazione della variabile di ambiente e quindi lo si genera ogni volta che si chiama un comando remoto.

Esempio: inserisci le variabili necessarie in ~ / .my_var.rc e poi per ogni comando remoto che esegui ssh user@remote bash -c "source ~/.my_var.rc; <your command>"

Se questo ti soddisfa, puoi quindi affinare questo concetto e copiarlo per comodità. Se ne hai bisogno solo per i comandi git, allora creerei uno script git.sh che farebbe questo:

#!/bin/bash

source ~/.my_var.rc

git $@

Supponendo che questo script sia nella tua home directory, lo chiameresti: ssh user@remote git.sh pull origin master

Nota: è un semplice punto di partenza. Ad esempio, non supporta i parametri con spazi.

Questo non risponde alla domanda generale su PATHS, ma ti consente di usare un repository git su un server remoto che non ha git nel suo percorso e al quale non hai accesso root. Questa soluzione proviene da questa pagina .

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

Per spingere e recuperare anche:

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

Il profilo / etc / verrà fornito su ogni connessione con ssh-client.