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?

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

You have few possibilities:

  • Set the PATH on the server in ~/.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.

  • 8
    Manually sourcing ~/.bashrc is not necesary, it happens by default. It fact, it seems to me like a bad idea.
    – ImHere
    Dec 25 '16 at 3:53
  • 1
    $PATH does not expand from ~/.ssh/environment, at least not in OpenSSH_7.9p1, OpenSSL 1.1.1b 26 Feb 2019.
    – Jaakko
    Oct 23 '19 at 8:31
  • 1
    @Jaakko It is probably disabled in sshd_config using PermitUserEnvironment (default in recent versions)
    – Jakuje
    Oct 23 '19 at 8:35
  • I figured it out, it was not expanding because I added a line PATH="$PATH:/new/path" to my ~/.ssh/environment when it should have been PATH=$PATH:/new/path
    – Jaakko
    Oct 23 '19 at 8:42
  • 1
    On MacOS Catalina OpenSSH_8.1p1 be warned you better do $ echo "PATH=$PATH" > ~/.ssh/environment cause $PATH does not expand Oct 21 '20 at 10:58

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


It is possible to execute commands (and set PATH or other environmental variables) in ~/.ssh/rc file. From man ssh:


Commands in this file are executed by ssh when the user logs in, just before the user's shell (or command) is started. See the sshd(8) manual page for more information.

sshd manual specifies this in its complete Login process description:

  1. If ~/.ssh/rc exists, runs it; else if /etc/ssh/sshrc exists, runs it; otherwise runs xauth. The ''rc'' files are given the X11 authentication protocol and cookie in standard input. See SSHRC, below.

The primary purpose of this file is to run any initialization routines which may be needed before the user's home directory becomes accessible; AFS is a particular example of such an environment.

This is from 2013 BSD manual. From my newer 2020 BSD manual for Arch Linux, these details are given:

  1. If ~/.ssh/rc exists and the sshd_config(5) PermitUserRC option is set, runs it; else if /etc/ssh/sshrc exists, runs it; otherwise runs xauth. The “rc” files are given the X11 authentication protocol and cookie in standard input. See SSHRC, below.

Probably because of this setting ~/.ssh/rc didn't work for me.

I couldn't find at what step sshd runs user's login scripts. Maybe it is set in ssh configuration scripts (in this case it is distribution-dependent).

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.