Il comando remoto SSH non legge tutte le variabili d'ambiente

4

Ho dichiarato alcune variabili "PATH" nel file ".bashrc" di una macchina remota. Quando accedo al computer remoto, tutte queste variabili "PATH" funzionano bene. Ma quando faccio un "utente ssh @ env remoto", i "PATH" dichiarati nel ".bashrc" non vengono letti. Come posso risolvere questo?

Questo è ".bash_profile" nella directory home sulla macchina remota:

# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
    . ~/.bashrc
fi

# User specific environment and startup programs
PATH=$PATH:$HOME/bin:

export PATH

Questo è ".bashrc" nella directory home sulla macchina remota:

# .bashrc

# Source global definitions
if [ -f /etc/bashrc ]; then
. /etc/bashrc
fi

# PATH
export PATH=$HOME/git-1.8/bin/:$PATH

E questo è l'output attuale del comando "ssh user @ remote env" dalla mia macchina locale:

SHELL=/bin/bash
SSH_CLIENT=NNNNNNNNNNNNNNN
USER=XXXXXXXXX
MAIL=/var/mail/XXXXXXXX
PATH=/usr/local/bin:/bin:/usr/bin:/usr/local/openssh/bin
PWD=/volume2/home/hp120242/XXXXXXXXX
SHLVL=1
HOME=/home/hp120242/XXXXXXXXXX
LOGNAME=XXXXXXXXXXXXX
SSH_CONNECTION=NNNNNNNNNNNNNNNNNNN
LC_CTYPE=en_US.UTF-8
_=/bin/env

Non ho i permessi di root sul telecomando.

git bash ssh

1

Sulla mia scatola, ripieno export HI=THERE in un altrimenti vuoto ~/.bashrc mostra questo output quando ssh viene usato per contattare la casella per un elenco env:

$ ssh $host /usr/bin/env 2>/dev/null | grep HI
HI=THERE

Mio ~/.bashrc prende l'approccio di controllare una variabile d'ambiente specifica dell'utente e quindi, se manca, fa l'equivalente di:

. ~/.profile   # load in (Bourne-shell syntax) baseline environment variables

Quindi, i miei comandi ssh - anche se bash si avvia come se fosse una subshell (solo .bashrc) - ottengono comunque le variabili d'ambiente che normalmente mi aspetto per le shell non interattive. Mi sembra di ricordare di averlo fatto esplicitamente per SSH molti anni fa.

Potresti avere il tuo ~/.profile imposta alcune variabili, ad esempio ENVGOOD=true, quindi hai questo nel tuo ~/.bashrc:

[ -z "$ENVGOOD" ] && . ~/.profile  # sets ENVGOOD=true

o creare a ~/.ssh/environment. Nota che quest'ultimo funzionerà solo se PermitUserEnvironment = true nel /etc/ssh/sshd_config è impostato, che è NON il default (e sicuramente perché il mio setup non si basa su di esso).

— Alex North-Keys
fonte

1

Vedi questa risposta: SSH non sta leggendo i file rc

.bash_profile non viene eseguito quando si esegue un comando perché SSH non esegue una shell di login, esegue il comando. Puoi provare a impostare le variabili di ambiente in ~/.ssh/environment ma è possibile che la lettura di questo file sia stata disabilitata.

Potresti provare a forzare una shell di login tramite: ssh user@host bash -lc env.

Come altri hanno menzionato .bashrc dovrebbe essere letto quando si esegue un comando. Puoi verificare che questo è il caso aggiungendo qualcosa di simile echo EXECUTED al superiore del tuo .bashrc.

È anche possibile che qualunque cosa sia dentro /etc/bashrc sta chiamando exit quindi tutto ciò che è sotto non viene eseguito.

— sshaw
fonte

Tuttavia, non dovrebbe essere originario di .bashrc?

— John Szakmeister

Ho creato un file ".ssh / environment" con la seguente riga "export PATH = $ PATH: $ HOME / git-1.8 / bin" nella cartella home remota, ma non ha cambiato nulla. Qualche altro suggerimento?

Sì, non capisco perché non viene originato.

Per .ssh/environment per funzionare, non è possibile esportare sulla linea e PermitUserEnvironment deve essere impostato nel sshd_config... quale @ jhaprade non ha alcun controllo.

— John Szakmeister

L'esecuzione di "ssh & lt; hostname & gt; env" legge definitivamente ~ / .bashrc sul Linux che sto usando, anche con i file .ssh /, .profile e altri .bash * nascosti. Mi sembra di ricordare questo, portando a strane circonlocuzioni per assicurarmi che leggesse nelle mie normali variabili di ambiente IFF che erano assenti. Si noti che ciò si adatta ancora all'idea che bash non venga chiamato come "shell di login", dato che sarebbe il .bash_login o .bash_profile o .profile.

— Alex North-Keys

0

Sulla macchina remota, verificare che il processo sshd non abbia un'opzione che sta sovrascrivendo il PERCORSO.

ps aux | grep sshd

— Chase T.
fonte

0

Su CentOS / RHEL, ho fatto quanto segue

ssh user@host "source .bash_profile; env "

Non dimenticarti di \ $ in modo da utilizzare le variabili di ambiente remoto. Per esempio, Il seguente comando stamperà lo stesso valore

echo $SSH_CLIENT; ssh user@host "source .bash_profile; echo $SSH_CLIENT "

Il comando qui sotto

echo $SSH_CLIENT; ssh user@host "source .bash_profile; echo \$SSH_CLIENT "

stamperà ciò che ti aspettavi.

— Steve Deackoff
fonte