Ssh Environment Variable for Sudo Access

ssh environment variable for sudo access

I found a solution.
Just remind that the issue was: how to invoke [sudo + command] taking into account that either *sudo or ssh has some limitation to able to see environment variables.* (see above in the question).

So we may use sudo like this:

 sudo env PATH=$PATH command

It will pass PATH variable into sudo context.

It was not obvious for me that we can use something different just after sudo.. not command but env

And we can NOT use

alias sudo='sudo env PATH=$PATH'

in ./.ssh/environment (ssh policy limitation - it does not allow it) and we can NOT use it in .bashrc (ssh policy limitation - it does not use it)

How to keep environment variables when using sudo

The trick is to add environment variables to sudoers file via sudo visudo command and add these lines:

Defaults env_keep += "ftp_proxy http_proxy https_proxy no_proxy"

taken from ArchLinux wiki.

For Ubuntu 14, you need to specify in separate lines as it returns the errors for multi-variable lines:

Defaults  env_keep += "http_proxy"
Defaults  env_keep += "https_proxy"
Defaults  env_keep += "HTTP_PROXY"
Defaults  env_keep += "HTTPS_PROXY"

How to make my environment variables available for sudo commands?

sudo has option -E or long-option --preserve-env for this.

Usage: sudo -E command args ...

Of course, you would need to export the variable from parent shell, in order for it to be visible to sudo.

proper way to sudo over ssh

Another way is to use the -t switch to ssh:

ssh -t user@server "sudo script"

See man ssh:

 -t      Force pseudo-tty allocation.  This can be used to execute arbi-
         trary screen-based programs on a remote machine, which can be
         very useful, e.g., when implementing menu services.  Multiple -t
         options force tty allocation, even if ssh has no local tty.

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

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.

Not able to set environment variable for sudo -u user

you need to run the db2profile when you sudo

sudo -u icinga sqllib/db2profile; '/usr/lib//nagios/plugins/check_db2_health' ...

Environment variables not loaded when executing command via `ssh` on remote machine

So after two hours of troubleshooting, I finally find the problem. It is because the following command in the beginning of .bashrc .

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

This prevents anything after that being executed in the environment of ssh <host> <command> .

If you have a similar issue try checking the beginning of the .bashrc file.

---

Related Topics