Once upon a time, an ssh invocation to host1 like ssh u@host1 command would read .bashrc before executing command. host2 is administered by the same people, and reads .bashrc!

I don't administer host1 or host2, but sometime in the last 6 months it seems this behaviour has changed.

It seems now that no rc file is being read on login: I edited .profile, .bash_profile, .bashrc, .login to append their name to a variable when read (export READ=$READ:.profile)

The results surprised me:

> ssh u@host1
bash3.2> echo $READ

As I expected.

> ssh u@host1 echo \$READ


So now I'm stuck. Any suggestions on how this could be happening? Is this a SSHd settings issue?

And just for info: host2 is running a version of OpenSSH even older than host1, and both are running the same bash version. host1 runs AIX, host2 runs linux.

Edit: I can't change the ssh command line because the goal here is to make git work properly, for a couple of non-super-users, where git is installed (for other reasons) on a non-standard path. The relation to this question is that because the location of git-unpack is specified in .bashrc, git clone from this remote has stopped working. So the RC problem needs to be fixed, because I'm trying to set this up for non-super-users, and so git-clone -u is not really a satisfactory answer.

  • 1
    Who is host2? You only mention host1 in your question. Are you connecting from a Linux machine?
    – terdon
    Mar 26, 2013 at 18:56
  • @terdon Whoops. Broke my train of thought and left a sentence fragment in there. Edited to add "host2 is administered by the same people, and reads .bashrc!"
    – Matthew G.
    Mar 26, 2013 at 19:02
  • I think file permissions changed when you edited the files. This has happened to me before, but I can't remember the fix =/
    – cutrightjm
    Mar 26, 2013 at 19:06
  • OK, this might be an AIX issue cause I can't replicate it when sshing between two linux boxes.
    – terdon
    Mar 26, 2013 at 19:10
  • 2
    I would be surprised if .bashrc were read, since ssh host1 echo \$READ doesn't start an interactive shell.
    – chepner
    Mar 27, 2013 at 13:08

1 Answer 1


In this particular instance, the answer appears (unfortunately) to be an instance of buggy software (or a bug very similar to that linked one).

If you control bash on that machine, you may be able to fix it by recompiling bash with #define SSH_SOURCE_BASHRC; However it's not the case for me, so I'm stuck seeking other options.

Hopefully that helps someone.

  • #define SSH_SOURCE_BASHRC saved my day. THX.
    – reen
    Sep 20, 2013 at 7:05
  • That may have worked but is not the correct answer. Per default bash reads the .profile, .bash_profile, .bash_login and .login on loging in from a remote. If you dont want them to be read try this --> ssh hostname "bash --noprofile"
    – konqui
    Mar 6, 2014 at 6:50
  • ssh hostname bash --noprofile isn't a prefect solution. Before your command is executed the remote host will still execute the user's default shell as a login shell which will still read things like .login. If the user has a particularly wonky/strange setup (eg., a .login that sources their .bashrc), it can still affect the environment before your command runs. Mar 16, 2015 at 17:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.