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

Question

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 ?

Probably because it isn't programming related. It should have been moved to Super User instead of closed. — Daniel H, Mar 07 '14 at 05:57
In Debian 8 I had to change the shell to bash in /etc/passwd for some reason. Even reconfigurung dash to let /bin/sh point to bash didn't help. — user1050755, Feb 09 '19 at 01:42
It could be that your *sshd* is configured with `UsePAM no`. If so, then the "PAM configuration for *sshd*" (`/etc/pam.d/sshd`), which usually takes care of automatically sourcing `/etc/environment`. ... Setting `UsePAM yes` (and restarting `sshd` once to apply this change) should now provide ssh login shells with `export`s from `/etc/environment`. ... as per https://man7.org/linux/man-pages/man5/sshd_config.5.html -> `UsePAM` documentation, depending on your needs, it may be recommended to then also set the following: `KbdInteractiveAuthentication no` and `PasswordAuthentication no`. — Abdull, Feb 09 '23 at 09:19

score 197 · Accepted Answer · answered Oct 19 '08 at 09:20

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.

Great answer, this was exactly the problem, the needed environment variables resided in /etc/bashrc, which is not sourced in non interactive mode. Moving them to /etc/profile solved the problem. Thank you very much! — Tom Feiner, Oct 19 '08 at 09:29
This answer in only a partial solution. Here's some more information: add a different environment variable (e.g. export SOURCED_SYSTEM_ETC_BASHRC) to the various files that get sourced: /etc/profile, etc/bashrc, ~/.profile, ~/.bash_profile, ~/bashrc. Then look for that unique variable in the Jenkins output. In my case, I updated /etc/bashrc to contain 'export SOURCED_SYSTEM_ETC_BASHRC=yes', and that variable showed up in the Jenkins log for the node. So in my case, to set environment variables for jenkins slaves they have to go in /etc/bashrc. Jenkins ssh login *only* sourced /etc/bashrc. — Coder Roadie, May 03 '16 at 21:49
That's quite a wall of text, I think it would be worth highlighting that `ssh user@host "bash --login -c 'command arg1 ...'"` will make the remote shell set up the login environment. The section you quoted does mention `--login` but it would be easy to overlook this. — codebeard, Nov 24 '16 at 03:17
Thank you for this post, I used `ssh bash --login my_script.sh` to run a script on the remote machine, works a treat and enabled me to successfully use local env vars like `JAVA_HOME` — markc, Jan 03 '20 at 15:28
In some UNIX system(like AIX), add environment variables into `/etc/profile` won't help, but `/etc/environment` works. — R.Liu, Dec 11 '20 at 07:57
A link to that bash man page section is https://www.mankier.com/1/bash#Invocation (I also made sure it is archived at https://web.archive.org/web/20230724100552/https://www.mankier.com/1/bash#Invocation) — Jeroen Wiert Pluimers, Jul 24 '23 at 10:13

Ian Vaughan · Answer 2 · 2011-06-01T08:44:24.360

129

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

edited Jun 01 '11 at 08:44

answered Sep 24 '09 at 15:29

Ian Vaughan

20,211
13
59
79

12

Having to always type extra code just to source the environment is ridiculous! – Michael Jan 08 '13 at 16:37
4

One rarely repeatedly types these sorts of things, normally it would be within a script, and as such, doesnt matter how much "extra code" there is, as long as it works :tm: – Ian Vaughan Jan 08 '13 at 16:47
2

If I source both /etc/profile and ~/.bash_profile (to get user additions to path) it works, but it's ugly. There must be an easier way to tell the command (in my case xterm) to use the "interactive" login and end up with the full user-specific path on the remote machine? – Jess Apr 03 '13 at 22:13
ssh $1 "source ~/.bashrc; ~/temp_unix.sh" Here temp_unix.sh has export MANI_HOME="mani deepak" but it is not working. – mani deepak Mar 25 '14 at 05:09
Another useful workflow (if script1.sh sources script2.sh): `scp script1.sh script2.sh user@host:/tmp/` followed by `ssh user@host "cd /tmp/ && ./script1.sh"` – blong Aug 13 '15 at 18:33
It can be difficult to work out which `bashrc` or `bash_profile` script is necessary to source. Instead, let `bash` handle this itself: `ssh user@host "bash --login -c 'command arg1 ...'"` – codebeard Nov 24 '16 at 03:12
Adding `. /etc/profile && nextCommand` helped. I found it cleaner if I were to use `bash -s < myscript` instead of typing one command after another, having to escape characters. Try `. /etc/profile && env` to see loaded variables. – Jan 23 '17 at 08:23
This doesn't work on my server. Strangely, if I do `ssh usr@host "export PATH=blablabla$PATH;env"` it work. – Tamaki Sakura Jan 23 '19 at 01:49

score 117 · Answer 3 · edited Dec 27 '19 at 06:05

117

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.

edited Dec 27 '19 at 06:05

Dmitri Zaitsev

13,548
11
76
110

answered Apr 03 '12 at 12:52

dpedro

1,397
1
9
8

1

perfection! +100 if I could :) – Dexter Sep 14 '12 at 01:13
VisualGDB was failing with the error "bash: gcc: command not found" and this solution rectified that. – KalenGi Feb 20 '13 at 13:27
This is perfect answer! – Jirapong Aug 27 '15 at 06:31
I didn't get how `.ssh/environment` can be helpful, but I totally understood `PermitUserEnvironment=yes`. Good one! – pg2455 Mar 19 '19 at 11:12
1

@pg2455 while you are not always able to configure sshd on your server (or don't want to enable it for all), you still can edit your user environment – dpedro Mar 19 '19 at 17:15
However, when I add my git installation to PATH, other regular binaries are not identified like ls, cd etc. – Amit P Apr 01 '19 at 06:11
Hi, may I ask where is the `sshd` file please? – Tengerye Aug 01 '21 at 09:23
@Tengerye /etc/ssh – teik Mar 30 '22 at 08:25

score 76 · Answer 4 · edited Jun 26 '12 at 18:56

76

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

edited Jun 26 '12 at 18:56

machineghost

33,529
30
159
234

answered Nov 13 '10 at 17:11

tomaszbak

8,247
4
44
37

13

Alternatively, you can just put all of your "non-interactive" code above that line. – machineghost Jun 26 '12 at 18:56
1

beautiful, saved me a lot of time :) thanks – Lance Sep 13 '13 at 06:25
Thanks. Just adding that the file with the return statement can be found at `/etc/bash.bashrc`. – adarshr Aug 10 '14 at 21:42
Is there anyway to bypass this code in the server without changing it? – Yoni Jul 30 '16 at 22:55
1

I spent so much time trying to understand why my script didn't work. Who thought it was a good idea to put these lines in the .bashrc ??? – Sharcoux May 31 '18 at 09:56

score 4 · Answer 5 · answered Jan 05 '11 at 19:13

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

Perfect! Nice one-line solution to the problem. – corpico Apr 07 '17 at 19:35 — corpico, Apr 07 '17 at 19:35

score 4 · Answer 6 · answered Feb 15 '12 at 06:27

4

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

answered Feb 15 '12 at 06:27

Michael MacDonald

259
3
8

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

6 Answers6

Linked

Related