Bug 458839

Summary: ssh'ing in to FC9 system doesn't run shell?
Product: [Fedora] Fedora Reporter: Stefan Llewellyn Smith <sgls>
Component: bashAssignee: Roman Rakus <rrakus>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: medium    
Version: 9CC: bugzilla, j.s.peatfield, kasal, rh-bugzilla, rrakus, tmraz, tsmetana, twaugh, yeti
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-06-10 08:18:29 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
patch that enables bash feature to run bashrc when opening a shell via ssh
none
patch to bash.spec to include previously attached patch during bash build none

Description Stefan Llewellyn Smith 2008-08-12 12:30:09 EDT
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_5_4; en-us) AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.2 Safari/525.20.1

When I ssh in to a system which I have just upgraded to FC9, only a bare environment exists. My .cshrc does not seem to be run, as it used to on FC8, and should according to man sshd_config.

Reproducible: Always

Steps to Reproduce:
1. ssh -x ebi printenv
2.
3.
Actual Results:  
USER=stefan
LOGNAME=stefan
HOME=/home/stefan
PATH=/usr/local/bin:/bin:/usr/bin
MAIL=/var/spool/mail/stefan
SHELL=/bin/tcsh
SSH_CLIENT=132.239.191.184 51160 22
SSH_CONNECTION=132.239.191.184 51160 132.239.20.203 22
HOSTTYPE=i386-linux
VENDOR=intel
OSTYPE=linux
MACHTYPE=i386
SHLVL=1
PWD=/home/stefan
GROUP=stefan
HOST=ebi.ucsd.edu
REMOTEHOST=
ARCH=i686
UNAME=Linux
LAMRSH=ssh -x



Expected Results:  
USER=stefan
LOGNAME=stefan
HOME=/home/stefan
PATH=/usr/kerberos/bin:/usr/lib/ccache:/usr/local/bin:/bin:/usr/bin:/usr/local/matlab702/bin:/home/stefan/bin:.:/usr/local/bin
MAIL=/var/spool/mail/stefan
SHELL=/bin/tcsh
SSH_CLIENT=132.239.191.184 51164 22
SSH_CONNECTION=132.239.191.184 51164 132.239.20.175 22
HOSTTYPE=i386-linux
VENDOR=intel
OSTYPE=linux
MACHTYPE=i386
SHLVL=1
PWD=/home/stefan
GROUP=stefan
HOST=kani
CERN=/usr/lib/cernlib
CERN_LEVEL=2006
CERN_VER=2006
CERN_ROOT=/usr/lib/cernlib/2006
LS_COLORS=
G_BROKEN_FILENAMES=1
SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
LANG=en_US.UTF-8
LESSOPEN=|/usr/bin/lesspipe.sh %s
NCARG_ROOT=/usr
NCARG_LIB=/usr/lib/ncarg
ARCH=i686
UNAME=Linux
LD_LIBRARY_PATH=/usr/X11R6/lib:/home/stefan/lib:/usr/local/lib
TEXINPUTS=.:~/latex:/usr/share/texmf/fonts/afm////:
BSTINPUTS=.:~/latex:
BIBINPUTS=.:~/latex:
TFMFONTS=.:~/fonts/tfm//:~/Japan/fonts/tfm//:
VFFONTS=.:~/fonts/vf//:
PKFONTS=.:~/fonts/pk//:~/Japan/fonts/pk/dnp:~/Japan/fonts/pk/modeless/jisx0208/jsso12:
LAMRSH=ssh -x



The Expected Results is from 

ssh -x kani

which is an FC 8 machine. The actual details aren't important, but it's clear that my .cshrc file is being read.

This is a potential major problem for running MPI and the like.
Comment 1 David Nečas 2008-09-11 09:31:32 EDT
> 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@UP.TO.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.
Comment 2 David Nečas 2008-09-12 03:23:52 EDT
> ...tweaking /etc/ssh/sshrc...

This is nonsense, the shell process is different, sorry.
Comment 3 Tomas Mraz 2008-09-12 05:28:54 EDT
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.
Comment 4 David Nečas 2008-09-12 06:42:51 EDT
> 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).
Comment 5 Tomas Mraz 2008-09-12 07:34:41 EDT
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.
Comment 6 Tomas Mraz 2008-10-15 16:37:40 EDT
I suggest enabling the bash compile time #define SSH_SOURCE_BASHRC.
Comment 7 Tomas Mraz 2008-10-22 13:00:51 EDT
*** Bug 468054 has been marked as a duplicate of this bug. ***
Comment 8 Roman Rakus 2008-10-23 08:54:54 EDT
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'.
Comment 9 Tomas Mraz 2008-10-23 09:01:42 EDT
There is the conditional on shell_level < 2.

The problem is in F9 and rawhide.
Comment 10 David Mansfield 2008-10-23 09:49:52 EDT
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.
Comment 11 David Mansfield 2008-10-23 09:51:33 EDT
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
Comment 12 David Mansfield 2008-10-23 09:52:50 EDT
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)
Comment 13 Roman Rakus 2008-10-23 10:09:48 EDT
Thanks for patch. I'm going to do F9 build.
for now fixed in rawhide:
  bash-3.2-28.fc10
Comment 14 Roman Rakus 2008-10-23 10:49:54 EDT
Changed in bash-3.2-23.fc9
Comment 15 Stefan Llewellyn Smith 2008-10-23 11:44:29 EDT
>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?
Comment 16 Tomas Mraz 2008-10-23 12:20:24 EDT
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.
Comment 17 Stefan Llewellyn Smith 2008-10-23 12:28:22 EDT
Indeed. I hadn't checked recently.
Comment 18 Roman Rakus 2008-11-05 10:04:54 EST
*** Bug 448476 has been marked as a duplicate of this bug. ***
Comment 19 Bug Zapper 2009-06-09 22:27:02 EDT
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
Comment 20 Roman Rakus 2009-06-10 07:29:43 EDT
Does problem still persist?
Comment 21 David Nečas 2009-06-10 07:55:24 EDT
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.
Comment 22 Roman Rakus 2009-06-10 08:18:29 EDT
ok, closing