How do you set the default ssh path for non-interactive logins in Lion?

It is not a good idea to rely on PATH for non-interactive scripts. You should always specify the full path of any executable.

Such scripts need to be able to bootstrap themselves. If you must have some environment variable set, create a wapper script that sets it and then calls your other script. That wrapper script can be as smart as your scripting language. It can detect your OS (or host) and set the environment appropriately.

I think that additional /etc/path and /etc/path.d information gets loaded when /etc/profile is invoked

# System-wide .profile for sh(1)

if [ -x /usr/libexec/path_helper ]; then
        eval `/usr/libexec/path_helper -s`
fi

if [ "${BASH-no}" != "no" ]; then
        [ -r /etc/bashrc ] && . /etc/bashrc
fi

Now why that would not be invoked for a non-interactive session is something I do not know.

If it is a specific usert account that gets invoked by your build agent, then maybe you can setup the extra PATH information in one of the user's config files

.bash_profile (or .bash_login, or .profile)

"man sshd" talks about ~/.ssh/environment, as well as ~/.ssh/rc and /etc/ssh/sshrc (I've never played with these, so your mileage may vary).

You may also want to look at the destination system's existing bash initialization file to see if there is logic that messes with the PATH based on whether it is being run interactive vs as a subshell. It would not be the first time ssh has been tripped up by the user's shell initialization file.

I wouldn't recommend trying to integrate automated tasks with a user interface session. You should be able to do anything you need with standard ssh public keys. I don't know what Electric Commander does for you. This sounds like the kind of thing people have been doing for years with scripts and cron.

I understand the general principle in using absolute paths in non-interactive sessions, but the simple fact is that this isn't always an option, particularly when you're using third-party tools that make use of ssh as an underlying communications mechanism.

A prime example of this that I'm encountering at the moment is git. I have git installed from the standard Mac OS X package, in the path it defaults to: /usr/local/git/bin. If you try to use git to access a remote repo on another machine directly, using ssh-based authentication, it will fail with the following message:

$ git remote -v

remoteMachine me@remotemachine:path/to/remote/repo (fetch)

remoteMachine me@remotemachine:path/to/remote/repo (push)

$ git fetch remoteMachine

Password:

bash: git-upload-pack: command not found

fatal: The remote end hung up unexpectedly

Linking all of the git executables into /usr/bin of course fixed this issue, though that's not my favorite solution. I did try to add the following to ~/.ssh/environment:

PATH=/usr/local/git/bin:$PATH

But that didn't affect my non-interactive path. I poked through different ssh man pages to see if it was possible, but couldn't find anything. Editing ~/.bash_profile didn't help either. sshd seems to keep pretty strict control over the PATH value.

Did you say

export PATH=/usr/local/git/bin:$PATH

in your .bash_profile?

If not, then you did not change PATH, you just changed a local variable that ssh cannot see.

Yeah, I set it up properly in my .bash_profile. I just avoided that nomenclature in the .ssh/environment definition, because the man page says that it specifically looks for "lines of the format ``VARNAME=value''".

It looks like the behavior is PATH-specific. If I do:

ssh remoteHost env

I can see that it's picking up all of the other environment variables I configure in my .bashrc file (which in turn is sourced from my .bash_profile script). But it won't take my path changes. I'm sure this is security-related. I'm just not sure how to override it.

Turns out it's possible with the ~/.ssh/environment approach I tried, but the sshd configuration has to support it, which it doesn't by default. I edited /etc/sshd_config with the following value:

PermitUserEnvironment yes

I was then able to add a PATH value to ~/.ssh/environment, which would then be read. NB: Setting in here will override the entire variable value, without the ability to be additive. E.g.

PATH=/usr/local/bin:$PATH

Will not work. Your path will end up being, literally:

/usr/local/bin:$PATH

You can basically do something like:

echo "PATH=$PATH" > ~/.ssh/environment

And go with the full path you've got at the time. I think I'm actually leaning towards just keeping the /usr/bin symbolic links, as all the conditional one-off path logic and configuration changes actually feel more hack-ish to me, at the end of the day.