Hide Forgot
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 used. 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: Always 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 http://www.snailbook.com/faq/sftp-corruption.auto.html 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.
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).
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 endif 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. --jh--
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.