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.
 
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