14

Assuming user has /bin/bash as the shell in /etc/passwd. Then ssh user@host command runs the command using Bash. However, that shell is neither login nor interactive, which means neither ~/.bash_profile nor ~/.bashrc is sourced. In that case how to set the PATH environment variable so that executables can be found and executed? Is it recommended to prefix the actual command with source ~/.bashrc?

  • 4
    .bashrc is sourced, but it probably has a test for interactivity at the top. Things you put before that check should apply, and that's what I do to force PATH when the server doesn't allow user environment or use ~/.pam_environment. – muru Dec 24 '16 at 12:41
11

You have got few possibilities:

  • Set the PATH in the server ~/.ssh/environment (needs to be enabled by PermitUserEnvironment yes in sshd_config).
  • Use full path to the binary
  • As you mentioned, manually source .bashrc: prefix the command with . ~/.bashrc (or source)

It pretty much depends on the use case, which way you will go.

  • 2
    Manually sourcing ~/.bashrc is not necesary, it happens by default. It fact, it seems to me like a bad idea. – sorontar Dec 25 '16 at 3:53
5

You are equating local settings to remote settings.

Locally, a bash instance, the present running shell in which you write:

ssh user@host command

Will execute the command ssh (nothing more) as a client ssh.
To do so the local shell needs not to start a sub-shell or a new shell or login.

The command is executed as a ls command is: locally.

It is the client ssh command that opens a network connection to a remote system, where, if correctly authenticated, a new shell will be started to execute the command written as an argument to ssh, or, if no argument is given, expect further commands on that connection.

That new Remote shell necessarily will be a login shell as the remote user (to that system) needs to be authenticated to login. Or, if some specific command is given, just run such command with the authenticated user privileges.

You could see which files are sourced by adding a $file sourced to the start of each file (in the remote system)(root is needed to change /etc/ files):

$ a=(~/.bashrc ~/.profile /etc/bash.bashrc /etc/profile)
$ for f in "${a[@]}"; do sed -i '1 i\echo "'"$f"' was read"\n' "$f"; done

And then just start a ssh console:

$ ssh sorontar@localhost
/etc/profile was read
/etc/bash.bashrc was read
/home/sorontar/.profile was read
/home/sorontar/.bashrc was read

In this case, both bashrc files were read because each profile file had commands to include them, not because the login shell directly sourced them.

$ ssh sorontar@localhost :
/etc/bash.bashrc was read
/home/sorontar/.bashrc was read

In this system, where bashrc is read in both cases.

No need to add a source ~/.bashrc to the command to execute.

Change PATH

All you need to do is include the correct settings to change the "$PATH", either in /etc/bash.bashrc for all users that start a shell in this system. Or in ~/.bashrc for each user that needs it. You could add (or edit) an skeleton of an user .bashrc to /etc/skel/ to have any new user created have the correct file available.

The above is valid only for bash. If you need the setting to work for all shells, probably setting the environment variable PATH using the ssh file ~/.ssh/environment for each user that need it. Or use /etc/ssh/sshrc for a global setting in the system where the ssh server is running (please read the Files section in man sshd for some additional detail).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.