464

When I ssh into my ubuntu-box running Hardy 8.04, the environment variables in my .bashrc are not set.

If I do a source .bashrc, the variables are properly set, and all is well.

How come .bashrc isn't run at login?

codeforester
  • 39,467
  • 16
  • 112
  • 140
Hobhouse
  • 15,463
  • 12
  • 35
  • 43
  • 120
    How on earth is this "off topic"? – Jonah Jul 20 '13 at 04:10
  • 14
    I'm not strict like this, but my guess is that this belongs in serverfault.com, superuser.com, or askubuntu.com – Michael Butler Jan 19 '14 at 17:08
  • 18
    @MichaelButler Agreed. Wonder why they don't move it instead of just close it down... – Luc May 04 '14 at 12:14
  • 4
    @Luc - Questions can only be moved within 60 days of being created. This question wasn't closed as off topic until 3 and a half years after it was created. I believe the 60 days rule has something to do with when the question databases are backed up or something... it becomes more difficult to migrate after that backup occurs. – ArtOfWarfare Sep 22 '15 at 16:15
  • 3
    I thought it was a pretty useful question. Encountered this issue when I had to ssh into machine A, in order to ssh into machine B (only accessible via A's local network). Taught me a practical difference between `.bashrc` and `.bash_profile` ! – information_interchange May 23 '19 at 02:58
  • A great answer is provided [here](https://unix.stackexchange.com/a/332533/393910). – Sasan May 29 '21 at 09:21

6 Answers6

806

.bashrc is not sourced when you log in using SSH. You need to source it in your .bash_profile like this:

if [ -f ~/.bashrc ]; then
  . ~/.bashrc
fi
Ayman Hourieh
  • 132,184
  • 23
  • 144
  • 116
  • Worked for me on Ubuntu 11.10 LAMP. Thanks! – Jorge Apr 17 '12 at 17:46
  • 45
    this should work on any sane distro with Bash, thus all these comments are obsolete :) –  Jul 02 '12 at 02:09
  • 1
    This isn't necessary with Ubuntu 12.04 LTS server, since `.bashrc` is sourced when you SSH in, by default. – orokusaki Dec 15 '12 at 02:53
  • Worked on Debian Squeezy fo me. Thanks – Antony Jan 23 '13 at 13:21
  • @orokusaki: I'm running a fresh install of 12.10 and .bashrc is not sourced by default. – Lester Peabody Mar 07 '13 at 13:16
  • 7
    @orokusaki: Correction, it is :) There was a rogue .bash_profile file which was forcing .profile to be skipped. – Lester Peabody Mar 07 '13 at 13:18
  • 1
    alternately it can be copyed from `/etc/skel/.bash_profile` into your home drive – GottZ Mar 23 '13 at 16:04
  • 5
    Like @LesterPeabody, my .bashrc wasn't being sourced on a Ubuntu 12.04 LTS server because of a rogue .bash_profile. It was created by the RVM install. I moved the RVM command to .profile and delete .bash_profile. All running fine now. – Rod Daunoravicius Oct 25 '13 at 10:02
  • See the @loic-wolff answer, the last on this page if you are login by terminal. – Razec Luar Nov 05 '13 at 12:03
  • A lot of people say that I **shouldn't** do this because it breaks rsync and the like. The other half says that I should do it because that's what makes it work. So... what is the final solution here...? – rr- Oct 11 '14 at 11:49
  • I had to run `chsh -s /bin/bash` in my script as the `vm` hadn't got `bash` setup as the ssh login shell. – Daithí Apr 05 '15 at 13:32
  • 7
    fwiw Debian Jessie/8 already sources `.bashrc` out-of-the-box - but it does it from `.profile`, not `.bash_profile`. – underscore_d Oct 18 '15 at 14:06
  • 1
    Debian Jessie did not source my .bashrc but working with .bash_profile. Regarding to this documentation it should read both .bash_profile & .profile in this order (https://wiki.debian.org/EnvironmentVariables) – Pipo Jun 20 '17 at 08:28
  • 2
    in one line: `[[ -f ~/.bashrc ]] && . ~/.bashrc` – ephemerr Apr 12 '18 at 07:41
  • 2
    Why is it `. ~/.bashrc` and not `source ~/.bashrc`? – PlasmaBinturong Mar 02 '21 at 14:33
106

I had similar situation like Hobhouse. I wanted to use the command

ssh myhost.com 'some_command'

where some_command exists in /var/some_location.

I tried to append /var/some_location to the PATH environment variable by editing $HOME/.bashrc but that wasn't working. Because per default, .bashrc (on Ubuntu 10.4 LTS) exits early due to this piece of code:

# If not running interactively, don't do anything
[ -z "$PS1" ] && return

Meaning if you want to change the environment for the ssh non-login shell, you should add code above that line.

Matthias Braun
  • 32,039
  • 22
  • 142
  • 171
ruseel
  • 1,578
  • 2
  • 21
  • 41
  • 1
    Cool tip dewd. I've run into this trap when running scripts from jenkins. I've logged via ssh and it worked. Jenkins logged non-interactively and it failed. – Krzysztof Jabłoński Aug 25 '14 at 11:59
  • 1
    Why the common solution is to not even set a new path for non-interactive shells is beyond me. There should be quite a bit above that if statement, for just this reason. Seems like only the aliases and the initialization of interactive tools should go below that line... – BenPen Sep 28 '16 at 19:44
  • 5
    On other version of Ubuntu the interactive check looks like: ```bash # If not running interactively, don't do anything case $- in *i*) ;; *) return;; esac ``` – Sylvain Jun 25 '18 at 05:33
  • Thanks, this solved it for me. Wish I'd seen this about an hour ago! – Justin Lawrence Aug 29 '18 at 11:42
  • From `man ssh`: " If a command is specified, it is executed on the remote host instead of a login shell." For me on Fedora Core 29 it doesn't call neither .bashrc nor .bash_profile when running commands (and calls them without commands). – Yaroslav Nikitenko Feb 25 '20 at 10:57
  • Been searching for how to get around this to deploy my apps easily using a single command. Thanks, dude, I wish I had found this months ago. I even started writing an app to ease my deployment – Shahid Kamal Dec 29 '21 at 08:20
38

For an excellent resource on how bash invocation works, what dotfiles do what, and how you should use/configure them, read this:

lhunath
  • 120,288
  • 16
  • 68
  • 77
37

If ayman's solution doesn't work, try naming your file .profile instead of .bash_profile. That worked for me.

Loïc Wolff
  • 3,205
  • 25
  • 26
  • 2
    Awesome. I lost 15 minutes on this detail. – vmassuchetto Mar 06 '12 at 19:06
  • 1
    i think .profile loads on GUI login. .bash_profile its for terminal logins. – Razec Luar Nov 05 '13 at 12:01
  • This also worked for SSH login to a Debian Jessie docker container (using a data only container for persistent storage) - BUT you may also want to check /etc/passwd to check your login shell is /bin/bash & not /bin/sh -------> /bin/dash – Stuart Cardall May 15 '15 at 22:27
  • 2
    @RazecLuar `.profile` is to be executed by _any_ login shell, regardless of whether said shell intends to spawn a GUI. Your comment totally contradicts the question and this answer, which clearly indicate that `.profile` is invoked on SSHing in - a distinctly non-GUI method. – underscore_d Oct 18 '15 at 14:05
0

Similar as @Loïc Wolff , Added below in my $HOME/.bash_profile Ubuntu 16

if [ -n "$BASH_VERSION" ]; then
    # include .bashrc if it exists
    if [ -f "$HOME/.bashrc" ]; then
        echo "Executed .bash_profile , calling .bashrc"
        . "$HOME/.bashrc"
    fi
fi
swaz
  • 321
  • 2
  • 5
0

I know its an old issue, but I was facing the same issue on Ubuntu 22.04.

have two identical servers, one of them source ~/.bashrc properly, I see colors once I login by ssh, the other was not

both servers had the exact same ~/.bashrc file

in my case the issue was when I installed golang using one liner on one of these two, it added new file ~/.bash_profile

that file only had three export path settings, so for some reason when I ssh this file was being source and not ~/.bashrc

removing .bash_profile and only keeping .bashrc solved the issue for me, or you can follow @swaz suggestion and keep both files

papanito
  • 2,349
  • 2
  • 32
  • 60
bodaay
  • 1