Red Hat Bugzilla – Full Text Bug Listing
|Summary:||ssh'ing in to FC9 system doesn't run shell?|
|Product:||[Fedora] Fedora||Reporter:||Stefan Llewellyn Smith <sgls>|
|Component:||bash||Assignee:||Roman Rakus <rrakus>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||9||CC:||bugzilla, j.s.peatfield, kasal, rh-bugzilla, rrakus, tmraz, tsmetana, twaugh, yeti|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-06-10 08:18:29 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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=184.108.40.206 51160 22 SSH_CONNECTION=220.127.116.11 51160 18.104.22.168 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=22.214.171.124 51164 22 SSH_CONNECTION=126.96.36.199 51164 188.8.131.52 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