Why does an SSH remote command get fewer environment variables then when run manually?
SshEnvironment VariablesSsh Problem Overview
I have a command that runs fine if I ssh to a machine and run it, but fails when I try to run it using a remote ssh command like :
ssh user@IP <command>
Comparing the output of "env" using both methods resutls in different environments. When I manually login to the machine and run env, I get much more environment variables then when I run :
ssh user@IP "env"
Any idea why ?
Ssh Solutions
Solution 1 - Ssh
There are different types of shells. The SSH command execution shell is a non-interactive shell, whereas your normal shell is either a login shell or an interactive shell. Description follows, from man bash:
A login shell is one whose first character of argument
zero is a -, or one started with the --login option.
An interactive shell is one started without non-option
arguments and without the -c option whose standard input
and error are both connected to terminals (as determined
by isatty(3)), or one started with the -i option. PS1 is
set and $- includes i if bash is interactive, allowing a
shell script or a startup file to test this state.
The following paragraphs describe how bash executes its
startup files. If any of the files exist but cannot be
read, bash reports an error. Tildes are expanded in file
names as described below under Tilde Expansion in the
EXPANSION section.
When bash is invoked as an interactive login shell, or as
a non-interactive shell with the --login option, it first
reads and executes commands from the file /etc/profile, if
that file exists. After reading that file, it looks for
~/.bash_profile, ~/.bash_login, and ~/.profile, in that
order, and reads and executes commands from the first one
that exists and is readable. The --noprofile option may
be used when the shell is started to inhibit this behavĀ
ior.
When a login shell exits, bash reads and executes commands
from the file ~/.bash_logout, if it exists.
When an interactive shell that is not a login shell is
started, bash reads and executes commands from ~/.bashrc,
if that file exists. This may be inhibited by using the
--norc option. The --rcfile file option will force bash
to read and execute commands from file instead of
~/.bashrc.
When bash is started non-interactively, to run a shell
script, for example, it looks for the variable BASH_ENV in
the environment, expands its value if it appears there,
and uses the expanded value as the name of a file to read
and execute. Bash behaves as if the following command
were executed:
if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi
but the value of the PATH variable is not used to search
for the file name.
Solution 2 - Ssh
How about sourcing the profile before running the command?
ssh user@host "source /etc/profile; /path/script.sh"
You might find it best to change that to ~/.bash_profile
, ~/.bashrc
, or whatever.
Solution 3 - Ssh
Shell environment does not load when running remote ssh command. You can edit ssh environment file:
vi ~/.ssh/environment
Its format is:
VAR1=VALUE1
VAR2=VALUE2
Also, check sshd
configuration for PermitUserEnvironment=yes
option.
Solution 4 - Ssh
I had similar issue, but in the end I found out that ~/.bashrc was all I needed.
However, in Ubuntu, I had to comment the line that stops processing ~/.bashrc :
#If not running interactively, don't do anything
[ -z "$PS1" ] && return
Solution 5 - Ssh
I found an easy resolution for this issue was to add source /etc/profile to the top of the script.sh file I was trying to run on the target system. On the systems here, this caused the environmental variables which were needed by script.sh to be configured as if running from a login shell.
In one of the prior responses it was suggested that ~/.bashr_profile etc... be used. I didn't spend much time on this but, the problem with this is if you ssh to a different user on the target system than the shell on the source system from which you log in it appeared to me that this causes the source system user name to be used for the ~.
Solution 6 - Ssh
Just export the environment variables you want above the check for a non-interactive shell in ~/.bashrc.