Why does an SSH remote command get fewer environment variables then when run manually?

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 ?

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.

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.

(As here (linuxquestions.org))

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.

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

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

Just export the environment variables you want above the check for a non-interactive shell in ~/.bashrc.