# Shell vs. SSH ${PATH} differs



## Leander (Aug 29, 2016)

Hi,

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


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


```
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:


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


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


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


```
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?


----------



## zirias@ (Aug 29, 2016)

See ssh(1):

```
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):

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

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


----------



## Leander (Aug 29, 2016)

Thanks. I almost thought so. How do I change this compiled content of ${PATH} to sshd?


----------



## Leander (Aug 29, 2016)

Reason:

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


----------



## zirias@ (Aug 29, 2016)

Leander said:


> Providing full binary paths in Perl scripts resolves my issue. But this is only a workaround in my eyes.


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.


----------



## Leander (Aug 29, 2016)

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?!


----------



## zirias@ (Aug 29, 2016)

See the quote from the manpage -- check the PermitUserEnvironment option. Still I insist this is a bad idea anyways.


----------



## fossette (Aug 31, 2016)

Leander said:


> ```
> ssh admin@192.168.10.52 '/bin/echo ${PATH}'
> /usr/bin:/bin
> ```



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.


----------



## Leander (Sep 6, 2016)

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?


----------



## ohauer (Sep 10, 2016)

Seems gitolite was not initialized.
Would you please post the output of the commands
`ls -la ~git/`
`awk '{print $1}' ~git/.ssh/authorized_keys`


----------

