Re: Proper way to set PATH environment with SSH non-interactive command
Thus said "Andy Bradford" on 04 Feb 2024 08:39:27 -0700: > 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? [For the archives] As it turns out, given that the shell does not itself read any profile configuration files for non-interactive shells, I can just update /etc/login.conf using ~/bin in the path: default:\ :path=~/bin /usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin /usr/local/sbin:\ Before: $ ssh localhost env | grep PATH amb@localhost's password: PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin After: $ ssh localhost env | grep PATH amb@localhost's password: PATH=/home/amb/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin Arguably, this could be done for a class that is assigned to different users for which this should apply so not everyone has this. Also, this does not impact interactive shells because, well, interactive shells read ~/.profile and consequently ENV applies. Andy
Re: Proper way to set PATH environment with SSH non-interactive command
Thus said "Allan Streib" on Sun, 04 Feb 2024 20:54:26 -0500: > Just send the full path to your script in the ssh command, and set up > the rest of the environment within the script. Yes, this too is an option. It may actually be the best option in my opinion. If the user knows that their binary is found in a non-standard path, then the simplest thing is to specify the full path to the binary and leave the environment alone. Thanks, Andy
Re: Proper way to set PATH environment with SSH non-interactive command
Just send the full path to your script in the ssh command, and set up the rest of the environment within the script.
Re: Proper way to set PATH environment with SSH non-interactive command
Thus said Kastus Shchuka on Sun, 04 Feb 2024 13:40:58 -0800: > SetEnv Directly specify one or more environment variables and their > contents to be sent to the server. Thank you this option looks like it could also work, except it's not one of which a user with no permissions can take advantage as the AcceptEnv option is disabled by default on most servers I imagine. So, while a normal user can set the environment for interactive shells, it seems that for non-interactive shells, the only viable solution is to prepend each command with the environment to be set (I see nothing in ksh(1) that suggests that the environment of non-interactive shells are under the control of the user). Also, I don't seem to be succesful in making SetEnv (or SendEnv) work. I've reconfigured (and restarted) sshd_config to have: AcceptEnv PATH Then I configured ~/.ssh/config with: Host localhost SetEnv PATH=/home/amb/bin:/bin:/usr/bin:/usr/local/bin When I run "ssh -v localhost env" I can see that the client sends the path: debug1: channel 1: setting env PATH = "/home/amb/bin:/bin:/usr/bin:/usr/local/bin" debug1: Sending command: env But env reports the following PATH: PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin I also tried using SendEnv but while the client sends the environment, the server seems to ignore it, even if I set the AcceptEnv pattern to *. # sshd -T -C user=amb,host=localhost | grep acceptenv acceptenv PATH When I run "sshd -d -d" I see the following in the output: debug2: Setting env 0: PATH=/home/amb/bin:/bin:/usr/bin:/usr/local/bin So it certainly looks like the server is accepting the path, however, env still reports a different path. Is this perhaps a bug? Maybe step 5 in LOGIN PROCESS is overwriting the PATH that was sent and received by the server? This is on OpenBSD 7.4. Thanks, Andy
Re: Proper way to set PATH environment with SSH non-interactive command
On Sun, Feb 04, 2024 at 08:39:27AM -0700, Andy Bradford wrote: > 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)? See ssh_config(5): SetEnv Directly specify one or more environment variables and their contents to be sent to the server. Similarly to SendEnv, with the exception of the TERM variable, the server must be prepared to accept the environment variable.
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
