[EMAIL PROTECTED] wrote:

> or /etc/ssh/* are screwed up.  After digging through workarounds, I am
> curious if not having "PermitUserEnvironment yes" in the global config
> is blocking ssh's ability to modify paths.  Unfortunately, I don't
> have admin access to the machine so I'm limited in what I can test and
> fix here on 4th of July weekend... :(

This is not related at all to your problem, as it's a separate ssh
feature that you are not using.  From man sshd_config:

Specifies whether ~/.ssh/environment and environment= options in
~/.ssh/authorized_keys are processed by sshd(8).

Besides, it's the shell and not sshd that is trying to modify the
environment by executing commands in .bashrc, so a sshd setting would
not have any effect.  You can see the entire sequence of steps that
takes place during ssh login in the section LOGIN PROCESS in ssh(8), but
note that the final step is "Runs user's shell or command" which means
that no matter what sshd does, environment modifications by the shell in
its startup file are going to override whatever sshd has done.

Add a temporary "echo" to your bashrc and see if you see that.  If not,
figure out why the shell isn't running its startup files.  But be sure
to remove the echo, because having a "clean" shell (i.e. free of stdout
spew) is important for commands that use ssh as transport, like git,
rsync and so on.

Brian

Reply via email to