Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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.

share|improve this question

migrated from stackoverflow.com May 17 '13 at 11:26

This question came from our site for professional and enthusiast programmers.

4 Answers 4

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

share|improve this answer

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.

share|improve this answer
    
Shouldn't .bashrc should still be sourced though? –  jszakmeister May 17 '13 at 5:06
    
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? –  jhaprade May 17 '13 at 5:08
    
Yes, I don't understand why is not being sourced. –  jhaprade May 17 '13 at 5:08
    
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. –  jszakmeister May 17 '13 at 5:13
    
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. –  Alex North-Keys May 17 '13 at 8:33

On the remote machine, verify your sshd process does not have an option that is overriding your PATH.

ps aux | grep sshd
share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.