Set PATH when SSH into MacOS

Question

My problem is

$ ssh localhost fswatch          
bash: fswatch: command not found

when without SSH command (i.e. fswatch) works fine.

I found that PATH in SSH session is default Mac's

$ ssh localhost echo \$PATH        
/usr/bin:/bin:/usr/sbin:/sbin

since without SSH

$ echo $PATH
/Users/kyb/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin

I really do not remember how have I set up the PATH, but sure ~/.bashrc and ~/.bash_profile do not edit PATH variable. There is a config file /etc/paths:

$ cat /etc/paths         
/usr/local/bin
/usr/bin
/bin
/usr/sbin
/sbin

Homebrew, npm, pip usually install programs to /usr/local/bin, so all installed programs are there and I can't access them via ssh localhost command on my MacOS. There is no problem with Linux.

So my question is how to configure OpenSSH to use PATHs from /etc/paths and /etc/paths.d?

I also tried to hack:

$ ssh localhost sh -lc 'echo empty;echo $PATH'

/usr/bin:/bin:/usr/sbin:/sbin
$ ssh localhost bash -lc 'echo empty;echo $PATH'

/usr/bin:/bin:/usr/sbin:/sbin

first line is always empty, don't you know why?

And my final workaround

$ ssh localhost bash -lc ':; 
    export PATH="$( cat /etc/paths /etc/paths.d/* | tr \\\\n : )"; 
    echo $PATH; 
    fswatch --version'
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/Applications/VMware Fusion.app/Contents/Public
fswatch 1.14.0
Copyright (C) 2013-2018 Enrico M. Crisostomo <enrico.m.crisostomo@gmail.com>.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Enrico M. Crisostomo.

Here first :; is important because first command is somehow dropped from execution

System: MacOS Mojave 10.14.5
ssh -V: OpenSSH_7.9p1, LibreSSL 2.7.3
bash --version GNU bash, version 5.0.7(1)-release (x86_64-apple-darwin18.5.0)

Answer 1

You can configure the SSH server to give clients a customized environment, including a custom PATH variable. You will need to configure 2 things:

1. Create the file ~/.ssh/environment on the server containing the following:

   PATH=/Users/kyb/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
   

2. Change the SSH server config file /private/etc/ssh/sshd_config to include the following line:

   PermitUserEnvironment PATH,LANG
   

Finally, restart/reload the SSH daemon on the server. SSH login clients should have access to your customized environment!

Answer 2

On my system I can just edit .bashrc and put this at the very top:

PATH=/my/path:$PATH

It is important to put it before:

# If not running interactively, skip the rest
[ -z "$PS1" ] && return

Answer 3

For my answer I assume you are using the Bourne Again SHell, but the following is true for most other shells as well:

The reason for the observed behavior is, that your command will not run in an interactive but a non-interactive shell:

When the user's identity has been accepted by the server, the server either executes the given command in a non-interactive session or, if no command has been specified, logs into the machine and gives the user a normal shell as an interactive session. All communication with the remote command or shell will be automatically encrypted.

- $ man ssh

I suspect that somewhere inside your .bashrc you extend your PATH variable. But BASH will not interpret your .bashrc file if you do not run an interactive shell:

When an interactive shell that is not a login shell is started, bash reads and executes commands from /etc/bash.bashrc and ~/.bashrc, if these files exist.

- $ man bash

So the easiest solution to this problem is to just provide the full path to the executable, like: $ ssh localhost /full/path/to/fswatch This is the most stable and secure solution to this problem and will always work!

When you connect to localhost you can leverage the which command: $ ssh localhost $(which fswatch). However, this will most probably not work, when you connect to another host.

Another, possible way would be to manipulate the PATH environment variable of the remote host for non-interactive shells (see @hedgie's answer). However, this poses security implications and therefore should not be used in production:

Enabling environment processing may enable users to bypass access restrictions in some configurations using mechanisms such as LD_PRELOAD.

- man sshd_config