Recent OpenSSH releases not reading .bashrc for ssh commands

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
As a heads up, some of you may notice a significant change in OpenSSH
behavior when you jump from RHEL 5 to RHEL 6, or sump to OpenSSH 5.x
as part of system upgrades. It's not well noted in the release notes,
but it is described in this bug report.

Basically, when running an "ssh" command without actually doing a
login, the ".bashrc" is no longer read. It wasn't *supposed* to be
read! Bash documentation shows that .bash_profile, etc. are only
invoked if there is an active login session, not for non-login
connections. So anyone reliant on PATH or alias settings in
their .bashrc will no longer get them without engaging in..... some
serious oddness, such as activating "environment" setttings in
sshd_config or actively sourcing your .bashrc as part of your ssh

Re: Recent OpenSSH releases not reading .bashrc for ssh commands

Quoted text here. Click to load it

.bashrd is read every time bash is invoked. .bash_profile, only when a
login shell is invoked. They are different animals. I have no idea how
ssh can invoke bash without it then reading .bashrc.
Ah, I do now-- ssh is probablyinvoking /bin/sh, not /bin/bash for some

--norc Do not read and  execute  the  personal  initialization  file
              ~/.bashrc  if the shell is interactive.  This option is on by
              default if the shell is invoked as sh.
Certainly an ssh invokation of bash, unless you are using ssh to run
another command directly, is an interactive session.

You could I suppose try
ssh remotecomputer bash

Re: Recent OpenSSH releases not reading .bashrc for ssh commands

Quoted text here. Click to load it
This option is on by
Quoted text here. Click to load it

Stop. *IF THE SHELL IS INTERACTIVE*. That's the problem.

An ssh command that starts a login session creates an interactive
shell, so it gets read.

If you simply execute a remote command, such as using "ssh remotehost
which svn", the .bashrc is no longer read. So if you have svn aliased
to something in your .bashrc, you no longer get the same svn.

This has turned out to be an enormous problem for git and svn users
who insist on using locally compiled versions of their tools instead
of the system /usr/bin/svn or /usr/bin/git. It's especially nasty if
you're on RHEL 5, you've installed an updated OpenSSH, and you try to
use 'svn+ssh:///svn@remotehost/reponame/' access for a designated
'svn' user and you expect it to use the svn enabled in the svn
user's .bashrc.

Quoted text here. Click to load it

Try with a recent OpenSSH, something more recent than OpenSSH 5.1, to
put 'export HARMLESS=3Dharmless' in your local host's .bashrc. Then run
    source .bashrc
    echo $HARMLESS
    ssh localhost 'echo $HARMLESS'

And you'll see precisely what I'm talking about.

This is a behavioral change, apparently in OpenSSH 5.2.

Site Timeline