Shell vs. SSH ${PATH} differs

Leander

Leander

Hi,

any ideas why ${PATH} is messed up / returns different content?

Code: 
ssh admin@192.168.10.52 '/bin/echo ${PATH}'
/usr/bin:/bin
while following command returns other PATH content:

Code: 
Leander@FreeBSD-01 [~]$ ssh admin@192.168.10.52
admin@FreeBSD-02 [~]$ echo ${PATH}
/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin
Have a look at my RC files:

Code: 
admin@FreeBSD-02 [~]$ cat ~/.bashrc
if [ -d /etc ] && [ -f /etc/bashrc ]; then
    source /etc/bashrc
elif [ -d /usr/local/etc ] && [ -f /usr/local/etc/bashrc ]; then
    source /usr/local/etc/bashrc
fi

Code: 
admin@FreeBSD-02 [~]$ cat /etc/bashrc
export PATH="/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin"

Code: 
admin@FreeBSD-02 [~]$ ls -lach /usr/local/etc/bashrc
lrwxr-xr-x  1 root  wheel    11B Aug 29 21:14 /usr/local/etc/bashrc -> /etc/bashrc

Code: 
cat /etc/profile | grep 'PATH'
Returns nothing, since PATH has not been set in it.

Why is ${PATH} not having the properties of /etc/bashrc?
 
See ssh(1):
Code: 
     PATH                  Set to the default PATH, as specified when
                           compiling ssh.
What you see is just the default builtin $PATH of ssh. If you give a command to ssh, this command is run instead of the user's default shell, so nothing else will happen to $PATH. A shell on the other hand will read its startup files and set $PATH itself.

In practice, this shouldn't be a problem. Tools, commands, shell scripts etc. should never rely on a specific value of $PATH. (edit: among other reasons because this would create security risks ...)

edit2: even more info from ssh(1):
Code: 
     If command is specified, it is executed on the remote host instead of a
     login shell.
that means also, if you specify shell commands, a shell WILL be executed, but not as a login shell -- it won't read all startup files.
Code: 
     Additionally, ssh reads ~/.ssh/environment, and adds lines of the format
     ``VARNAME=value'' to the environment if the file exists and users are
     allowed to change their environment.  For more information, see the
     PermitUserEnvironment option in sshd_config(5).
so there IS a way to have some defined environment for any command, but use this with care, security should be a concern here.
 
Reason:
Code: 
User@FreeBSD-01 [~]$ ssh git@FreeBSD-02
PTY allocation request failed on channel 0
WARNING: Can't exec "git": No such file or directory at /usr/local/lib/perl5/site_perl/Gitolite/Rc.pm line 288, <DATA> line 1.
WARNING: Use of uninitialized value in substr at /usr/local/lib/perl5/site_perl/Gitolite/Rc.pm line 288, <DATA> line 1.
WARNING: substr outside of string at /usr/local/lib/perl5/site_perl/Gitolite/Rc.pm line 288, <DATA> line 1.
WARNING: Use of uninitialized value $gv in concatenation (.) or string at /usr/local/lib/perl5/site_perl/Gitolite/Rc.pm line 301.

hello Leander, this is git@FreeBSD-02 running gitolite3 v3.6.5 on git
R W    gitolite-admin
R W    testing
Connection to FreeBSD-02 closed.
User@FreeBSD-01 [~]$

Providing full binary paths in Perl scripts resolves my issue. But this is only a workaround in my eyes.
 
Leander said:
Providing full binary paths in Perl scripts resolves my issue. But this is only a workaround in my eyes.
Click to expand...
Well, that's the preferred way. Reason is security. Imagine some malware tinkering with your bash config files, this could make you execute a git binary from a user-writable location -- of course modified and full of harmful code ;)

But if you insist on doing dangerous things, see my edit above.
 
Thanks for your contribution. Unfortunately setting "PATH=/usr/local/bin" in ~/.ssh/environment didn't do the job. I tried finding a tutorial related to FreeBSD for gitolite, but I seem to be the only one with this issue?!
 
See the quote from the manpage -- check the PermitUserEnvironment option. Still I insist this is a bad idea anyways.
 
Leander said:
Code: 
ssh admin@192.168.10.52 '/bin/echo ${PATH}'
/usr/bin:/bin
Click to expand...

I did this path check on my server out of curiosity, and what I see is a full shell path (with sbins, and all). I don't even use PermitUserEnvironment which is no by default in etc/ssh/sshd_config. It's useful for me because of the commands I use, but should I be concerned about the security? If run, malware would gain all user privileges as well...

I guess I should further study the firewall rules to discourage brute force attempts...

Dominique.
 
Then I assume devel/gitolite can be considered as broken port, since it does not work without modifying lots of its source code manually before it can be run?
 
Seems gitolite was not initialized.
Would you please post the output of the commands
ls -la ~git/
awk '{print $1}' ~git/.ssh/authorized_keys
 
You must log in or register to reply here.
Back
Top