My Bash aliases are not working over ssh, for example:

$ ssh remote_name ll dir_name
bash: ll: command not found

The Bash man page says:

Aliases are not expanded when the shell is not interactive,
unless the expand_aliases shell option is set using shopt...

So I added shopt -s expand_aliases at the top of my ~/.bashrc file in both the local and remote .bashrc files (since I wasn't sure which was needed - remote right??).

I restarted the local Bash and tried ssh remote_name ll dir_name again, unfortunately I still got the same error bash: ll: command not found.

Can anyone explain what I should do to get this working please?

Just in case my Bash versions are:

Local Bash:
$ bash --version 
GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)

Remote Bash:
$ bash --version 
GNU bash, version 4.3.30(1)-release (x86_64-pc-linux-gnu)

3 Answers 3


~/.bashrc is read by an non-login, interactive session of bash, not by non-interactive sessions.

ssh remote some_command is running some_command in an non-interactive session of bash, hence the remote ~/.bashrc is not being read (and of course reading the local one is out of question).

Precisely, non-interactive session of bash can read the file defined by the environment variable BASH_ENV or ENV (if set).

If you want to stick with the aliases, open the shell in interactive mode too:

ssh remote bash -ic 'll'

Also note that, aliases are standalone, they don't take any argument like you are providing a directory name. You need to use functions to have arguments as inputs. A similar function definition would be:

ll_f () { ls -al --color=auto "$@" ;}

Now you can do:

ll_f /dir_name
  • Thanks, the alias itself works (ll gives me the -l listing) but when I add a directory name, ssh remote bash -ic 'll dir_name', it gives me just the full listing of ~/ and not of dir_name.
    – mattst
    Aug 14, 2016 at 11:32
  • 1
    @mattst Check my edits
    – heemayl
    Aug 14, 2016 at 11:37
  • Thanks, ssh remote ll_f dir_name works a treat.
    – mattst
    Aug 14, 2016 at 11:52
  • 2
    NOTE: .bashrc may be read by non-interactive sessions. $ head -1 .bashrc echo RUNNING BASHRC $ ssh localhost echo hello RUNNING BASHRC hello Aug 14, 2016 at 14:17

My favorite way (in ~/.bashrc):

function bassh() {
    local host=${1:?'arg #1 missing: remote host'}
    local command="$@"
    local usage="bassh REMOTE_HOST COMMAND"

    [ "$command" ] || {
        echo -e >&2 "[error] no command provided\nUsage: ${usage}"
        return 1

    ssh ${host} -t bash -ic "'${command}'"

Note the -t option to ssh which forces pseudo-terminal allocation, thus avoiding related warnings.

Then you call it simply:

$ bassh REMOTE_HOST ll


 #!/bin/bash -l

it resolved the issue

  • Are you sure it resolved the issue described by the OP? -l makes bash act like a login shell, which means it won't read .bashrc.
    – JigglyNaga
    Oct 5, 2018 at 16:10

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.