Bug 458839

> This is a potential major problem for running MPI and the like.

This is a very real problem that borked a PVM cluster for me.  The problem appeared after the update

openssh-server-5.0p1-3.fc9 -> openssh-server-5.1p1-2.fc9

To check the problem is not caused by something specific to my account, I created a new user with defaults (i.e. bash shell):

    adduser -m sshtestuser

and changed his ~/.bashrc contents to

-----------------------------------------------------------
# .bashrc

echo '~/.bashrc is being sourced!'
VARIABLE=value

# Source global definitions
if [ -f /etc/bashrc ]; then
	. /etc/bashrc
fi

# User specific aliases and functions
-----------------------------------------------------------

Now

     ssh sshtestuser.DATE.FEDORA9.MACHINE 'echo $VARIABLE'

prints just an empty line with openssh-server-5.1p1-2.fc9 while downgrading to openssh-server-5.0p1-3.fc9 brings the expected output

-----------------------------------------------------------
~/.bashrc is being sourced!
value
-----------------------------------------------------------

It is possible to restore (well, sort of) the processing of shell rc files by tweaking /etc/ssh/sshrc, but who knows what security implications such `solution' can have...

The value of $0 and $- are `bash' and `hBc' with both openssh versions, BASH_ENV is unset.

> ...tweaking /etc/ssh/sshrc...

This is nonsense, the shell process is different, sorry.

The problem is the .bashrc was sourced on older versions just by coincidental circumstances. The .bashrc should be read by bash only when the shell is interactive or when the stdin is a socket. In the 5.0p1 and older versions the stdin was socket but that caused other problems. Now the stdin is pipe and thus the .bashrc is not read.

Note that for example ssh -t <user@host> printenv does not read .bashrc even on old ssh versions.

So the question is how to proceed. CCing bash maintainers as bash has explicit code to allow reading .bashrc when it detects it is invoked from SSH, but I am not sure whether enabling that code could not break anything.

For the original report - If your shell in passwd is csh/tcsh I don't really understand why the .cshrc or .tcshrc is not read because from looking at the tcsh manpage it does not seem tcsh should be distinguishing interactive mode. It should always read .cshrc when -f option is not used and that is surely not the case. So I suppose there might be 2 different issues.

> The problem is the .bashrc was sourced on older versions just by coincidental
> circumstances.

I realized this too, but I'm afraid everyone took this feature for granted for a long time...

The biggest issue for me is that there seems to be no method to get the old behaviour that would work now.  Even patching bash would leave a window of brokeness, i.e. some version combinations just won't work now matter what.

For PVM, enabling PermitUserEnvironment (which understandably many people are reluctant to do) and using ~/.ssh/environment would probably suffice.  Unfortunately, this file permits only bare static assignments that are not always  practical (or even sufficient).

Actually there is a workaround - you can modify sshd PAM configuration by adding line 
session    optional     pam_env.so conffile=/etc/ssh/env.conf envfile=/etc/ssh/environment

to the end of /etc/pam.d/sshd. And putting BASH_ENV=~/.bashrc to the /etc/ssh/environment. The /etc/ssh/env.conf can be empty file. The BASH_ENV should then be cleared in the system bashrc file so the .bashrc is not sourced in the following invocations of sh inside the session.

Unfortunately putting this to the default sshd PAM configuration in the package is not an option either.

I suggest enabling the bash compile time #define SSH_SOURCE_BASHRC.

*** Bug 468054 has been marked as a duplicate of this bug. ***

Defining SSH_SOURCE_BASHRC looks like best solution. But not even this is good. Is this problem also in rawhide? I prefer to change it there.
Defining SSH_SOURCE_BASHRC will cause sourcing .bashrc by executing non-interactive commands with `bash -c'.

There is the conditional on shell_level < 2.

The problem is in F9 and rawhide.

this is critical to a bunch of users here who use Fedora 9 as a dev. platform.  i've adopted the approach suggest in comment#8, and I've attached the patch to the bash-3.2 upstream and the patch to the bash.spec to incorporate the prev. patch into the build.  not sure if this is the best way to help or not.

i've tested that the fix DOES work.  i've also tested that the shell_level < 2 restriction in comment#9 is working properly.

Created attachment 321287 [details]
patch that enables bash feature to run bashrc when opening a shell via ssh

necessary fix to bash since ugrading to openssh-5.1

for building bash RPM, see following patch to bash.spec to include this patch during the build

Created attachment 321288 [details]
patch to bash.spec to include previously attached patch during bash build

this patch to the bash spec includes the previously attached patch to bash that enables running bashrc when ssh'ing into a host and running an non-interactive command (behaviour which broke when upgrading to openssh 5.1)

Thanks for patch. I'm going to do F9 build.
for now fixed in rawhide:
  bash-3.2-28.fc10

Changed in bash-3.2-23.fc9

>For the original report - If your shell in passwd is csh/tcsh I don't really
>understand why the .cshrc or .tcshrc is not read because from looking at the
>tcsh manpage it does not seem tcsh should be distinguishing interactive mode.
>It should always read .cshrc when -f option is not used and that is surely not
>the case. So I suppose there might be 2 different issues.

I agree.

 I don't even use bash. Does this mean the fix should (also) be in openssh?

Actually .cshrc is read, I've just tested it. So I don't see any bug in regards to tcsh vs openssh-5.1p1.

The only problem is with bash.

Indeed. I hadn't checked recently.

*** Bug 448476 has been marked as a duplicate of this bug. ***

This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Does problem still persist?

I was not following much closely because we had to start set up things differently where this hurt, i.e. in PVM clusters, anyway.  But with

openssh-server-5.2p1-2.fc11.x86_64
bash-4.0-6.fc11.x86_64

.bashrc seems sourced for remote commands specified on ssh command line.  So, it works for me.

ok, closing