Sunday, February 04, 2024

Proper way to set PATH environment with SSH non-interactive command

Hello,

When using SSH to invoke a remote command via the syntax:

ssh remotehost remotecommand

The $HOME/.profile is not used and there appears to be a very minimal
environment setup. The PATH does not include any components that have
been added in .profile.

This is probably what step 5 in the LOGIN PROCESS is all about:

http://man.openbsd.org/sshd#LOGIN_PROCESS

According to the man page for sshd(8):

After this, the client either requests an interactive shell or execution
of a non-interactive command, which sshd will execute via the user's
shell using its -c option.

So in the case where an interactive shell is chosen, the PATH will be
set according to .profile, but in the case where a non-interactive
command is chosen, a shell is invoked with -c. So I have a script in
$HOME/bin (which is defined in PATH normally in .profile) which I can
run when logged in interactively:

$ helloworld
HELLO WORLD

But when I try to run it as a non-interactive command, it fails:

$ ssh localhost helloworld
amb@localhost's password:
ksh: helloworld: not found

Obviously, one way to do this is by calling the command like:

$ ssh localhost PATH=\$HOME/bin:\$PATH helloworld
amb@localhost's password:
HELLO WORLD

This works and can be seen in ssh -v output as:

debug1: Sending command: PATH=$HOME/bin:$PATH helloworld

But is there a file that I can modify that will cause the shell proper
to load some kind of environment setup also for non-interactive shells
started with -c?

sshd does have PermitUserEnvironment and that works, however, it's not
enabled by default and it's not a function of the SHELL proper. From a
user perspective, it seems that the user only has control of the
environment when using interactive shells and there is no way to control
the environment for non-interactive shells (from the remote side). Are
these the only 2 options (PermitUserEnvironment or prepend the command
with the environment) or is there something I'm missing from ksh(1)?

Thanks,

Andy

No comments:

Post a Comment