4

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
:.bash_profile:.profile

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.

Improve this question
15
  • 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

Reset to default
4

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.

Improve this answer
3
  • #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.
    – Brian Vandenberg
    Mar 16, 2015 at 17:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .