Bug 59249 - OpenSSH reads rcfile in non-interactive shells
OpenSSH reads rcfile in non-interactive shells
Product: Red Hat Linux
Classification: Retired
Component: openssh (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2002-02-03 17:31 EST by Need Real Name
Modified: 2007-04-18 12:39 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-02-20 13:06:54 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2002-02-03 17:31:16 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20020104

Description of problem:
OpenSSH is causing the "~/.bashrc" file to be read for 
non-interactive shells.  This includes when "scp" is being

This is _very_ annoying because it means there is nowhere
to put stty commands or send messages at login, because
OpenSSH wil stupidly invoke these interactive shell resources.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
To see this do the following.

  + For each F in "/etc/ssh/sshrc", "~/.ssh/rc", "/etc/profile",
                  "~/.bash_profile", "/etc/bashrc", and "~/.bashrc"
    on the host and target account do the following.

      - Prepend the lines (replacing %F with the filename)

echo "In %F for USER=\"${USER}\"," >> /tmp/ssh-errors.txt
echo "with PS1=\"${PS1}\"," >> /tmp/ssh-errors.txt
echo "with ENV=\"${ENV}\", and" >> /tmp/ssh-errors.txt
echo "with BASH_ENV=\"${BASH_ENV}\"." >> /tmp/ssh-errors.txt

      - Comment out the usual references to other rc files.

Now for a warm up see what happens when you execute

    /bin/bash -c "/usr/bin/env"

from within the target account.  According to 


this is the intended effect of running ssh, scp, etc.  So have
a look at "/tmp/ssh-errors.txt".  On my RedHat 7.2 box it remains
empty because this is neither a login nor an interactive shell.

However, when we do the same from another RedHat 7.2 host via
the OpenSSH command

    ssh andrew@hostname "/usr/bin/env"

"/tmp/ssh-errors.txt" now contains the lines

In .ssh/rc for USER="andrew",
with PS1="",
with ENV="", and
with BASH_ENV="".
In .bashrc for USER="andrew",
with PS1="",
with ENV="", and
with BASH_ENV="".

The first reference is expected.  The sshd(8) manpage explains
that "~/.ssh/rc" wil be sourced, but there is no explanation
for "~/.bashrc" being sourced.  Not even the one caused by
the earlier RedHat practice of setting ENV to this file.
Furthermore, the shell is clearly non-interactive because PS1
is _not_ set.

Actual Results:  In .ssh/rc for USER="andrew",
with PS1="",
with ENV="", and
with BASH_ENV="".
In .bashrc for USER="andrew",
with PS1="",
with ENV="", and
with BASH_ENV="".

Expected Results:  In .ssh/rc for USER="andrew",
with PS1="",
with ENV="", and
with BASH_ENV="".

Additional info:

This bug is described for RedHat 7.2 and openssh-2.9p2-12.
Comment 1 Pavel Kankovsky 2002-02-12 13:56:54 EST
This appears to be a "feature" of bash (default for versions <2.05a-rc1, optiona
depending on whether SSH_SOURCE_BASHRC is defined since 2.05a-rc1). It reads
.bashrc whenever it sees $SSH_CLIENT or $SSH2_CLIENT. Apparently, the idea was
to make it backward compatible with rsh because bash run under rsh is supposed
to read .bashrc (God knows why but it's documented).
Comment 2 Joe Harrington 2002-02-20 13:06:50 EST
The reason that rc files are read during an ssh shell (and were in rsh shells)
was so that the user could set PATH and other environment variables and do other
configurations that would normally exist were they actually logged into the
remote machine.  This is important, for example, if your ssh runs a command that
runs other programs, and that initial command does not call them with absolute
paths.  What that initial command does can be out of the user's control.  In
your bash -c example, you already had your environment set up and it got
inherited by the command you ran.  This wouldn't have happened under your
desired behavior.  However, most users (possibly including you) would want their
PATH, etc., set to include things like personal bin directories.

The traditional way to deal (I have old dotfiles dating to 1985 that do this for
rsh) is to protect things you only want sourced in interactive shells with
something like:

if ( -r ~/.int_cshrc && $?prompt ) then	# only if shell is interactive
  source ~/.int_cshrc
in your .cshrc or an equivalent file for bash or another shell.  Of course, you
can just include the commands in the conditional if you want, rather than
sourcing another file.  I use separate files so that I can source my .int_cshrc
when I su without getting my normal path.

The reason it isn't a login shell is that login shells often start background
jobs that you wouldn't want started for just a remote command, and the notion of
a non-interactive login shell is, well, fishy.  The goal is to get the
environment set up and that's it.

Comment 3 Nalin Dahyabhai 2002-03-07 11:51:59 EST
This is not an OpenSSH bug.  This is the expected behavior for bash.  Commands
which must be run for interactive logins only should be placed in ~/.bash_profile.

Note You need to log in before you can comment on or make changes to this bug.