SSH remote command no reading all environment variables

Question

I have declared some "PATH" variables in the ".bashrc" file of a remote machine. When I login to the remote machine, all these "PATH" variables work fine. But when I do a "ssh user@remote env", the "PATH"s declared in the ".bashrc" are not read. How can I fix this?

This is the ".bash_profile" in the home directory on the remote machine:

# .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

This is the ".bashrc" in the home directory on the remote machine:

# .bashrc

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

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

And this is the present output of the command "ssh user@remote env" from my local machine:

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

I don't have root permissions on the remote.

Solution 1

On CentOS/RHEL, I've done the following

ssh user@host "source .bash_profile; env "

Do not forgot to \$ so that you use the remote environment variables. For example, The following command will print the same value

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

The command below

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

will print what you expected.

Solution 2

On my box, stuffing export HI=THERE into an otherwise empty ~/.bashrc shows this output when ssh is used to contact the box for an env listing:

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

My ~/.bashrc takes the approach of checking for a user-specific environment variable and then, if it's missing, does the equivalent of:

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

Hence, my ssh commands - even though bash starts up as though it's a subshell (.bashrc only) - still get the environment variables I normally expect for non-interactive shells. I t seem to remember doing this explicitly for SSH many years ago.

You could have your ~/.profile set some variable, say ENVGOOD=true, then have this in your ~/.bashrc:

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

or create a ~/.ssh/environment. Note that this latter will only work if PermitUserEnvironment = true in the /etc/ssh/sshd_config is set, which is NOT the default (and assuredly why my setup doesn't rely on it).

Solution 3

See this answer: SSH not reading rc files

---

.bash_profile is not executed when running a command because SSH does not execute a login shell, it executes the command. You can try setting the environment variables in ~/.ssh/environment but it's possible that the reading of this file has been disabled.

You could try forcing a login shell via: ssh user@host bash -lc env.

As others have mentioned .bashrc should be read when running a command. Can you verify that this is the case by adding something like echo EXECUTED to the top of your .bashrc.

It is also possible that whatever is in /etc/bashrc is calling exit so anything below that is not run.

Comments

[user1165419]

I created a ".ssh/environment" file with the following line "export PATH=$PATH:$HOME/git-1.8/bin" at the remote home folder but it didn't change nothing. Any other suggestions?

[John Szakmeister]

For .ssh/environment to work, you cannot have export on the line, and PermitUserEnvironment needs to be set in the sshd_config... which @jhaprade has no control over.

[Alex North-Keys]

Running "ssh <hostname> env" definitely reads the ~/.bashrc on the Linux I'm using, even with the .ssh/, .profile and other .bash* files hidden. I seem to remember this leading to some strange circumlocutions in making sure it read in my normal environment variables IFF they were absent. Note that this still fits the idea of bash not being called as a "login shell", since that would be the .bash_login or .bash_profile or .profile instead.