Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This problem comes up with me trying to make svnserve (Subversion server) available on a server through SSH. I compiled SVN and installed it in $HOME/bin. Local access to it (not through SSH) works fine.

Connections to svn+ssh fail due to:

bash: svnserve: command not found

Debugging this, I've found that:

ssh user@server "which svnserve"


which: no svnserve in (/usr/bin:/bin)

This is strange, because I've updated the path to $HOME/bin in my .bashrc, and also added it in ~/.ssh/environment. However, it seems like the SSH doesn't read it. Although when I run:

ssh user@server "echo $PATH"

It does print my updated path!

What's going on here? How can I make SSH find my svnserve? Thanks in advance

share|improve this question
When you run 'ssh user@server "echo $PATH"', $PATH gets expanded locally so what you get is PATH on localhost. Try escaping $ like so "echo \$PATH". (doesn't solve your problem, but will help with troubleshooting). – Shawn Chin Apr 9 '10 at 8:47
@lsc: this explains the "echo $PATH" mystery, thanks – Eli Bendersky Apr 9 '10 at 8:57
BTW, you may want to update the title to reflect your actual problem (i.e. svn+ssh). That should help you get more relevant answers. – Shawn Chin Apr 9 '10 at 15:00

You can try launching the command via a bash using the -l command so it acts as a login shell

ssh user@server "bash -l -c 'which svnserve'"

As noted in comments I left above, you'll need to escape all $ so variables get expanded on the server and not locally. E.g.:

ssh user@server "bash -l -c 'echo \$PATH'"


Regarding you question on why .ssh/environment does not take effect, I believe the default config for SSHd would be to ignore user environments. You need to specifically enable it in /etc/ssh/sshd_config (or similar) and add:

PermitUserEnvironment yes

update 2:

If you do not have access to /etc/ssh/sshd_config, a possible (but not ideal) solution would be to use public-key authentication to launch svnserve on login.


Note that this will affect your ability to log in normally via SSH. To do so, you need to bypass the public key authentication:

svn -o PubkeyAuthentication=no user@server
share|improve this answer
Thanks, this makes sense. Unfortunately it still doesn't resolve my original problem which is running svnserve via SSH. for some reason ssh ignores my .ssh/environemnt file and every other attempt I try – Eli Bendersky Apr 9 '10 at 8:57
@Eli answer updated to address .ssh/environment issue – Shawn Chin Apr 9 '10 at 12:58
Oopps.. just notices that @Dennis has already pointed you that way. Apologies for the repetition. – Shawn Chin Apr 9 '10 at 12:59
Thanks. Unfortunately since this is a shared server I have no access to /etc/ssh/sshd_config. But from tests I ran it appears this variable indeed isn't set, because ssh ignores my environment file for sure – Eli Bendersky Apr 9 '10 at 13:01

As it happens, .bashrc and .bash_profile are only executed if you're in an interactive shell. When you login through ssh, you are not in an interactive shell, therefore your custom PATH definitions are never run. You can associate a script to non-interactive sheels using BASH_ENV. Check also .ssh/environment which gives you another alternative. The best way to know about this is by doing man ssh.

Good luck!

share|improve this answer
Sorry, but I noted that .ssh/environment didn't work for me. Any tips of what to write there? Also, I was under the impression that .bashrc is included in non-interactive shells. Otherwise, how is my PATH given correctly via ssh? (echo $PATH)? – Eli Bendersky Apr 9 '10 at 8:20

You can execute an env command:

ssh servername "env PATH=$REMOTEPATH which svnserve"
share|improve this answer
after adding a semicolon before which, it says: which: no svnserve in (/usr/bin:/bin) – Eli Bendersky Apr 9 '10 at 9:09
@Eli: no semicolon - which is an argument to env – Charles Stewart Apr 9 '10 at 18:01

I have the same issue with HostMonster, due to a recent change they made. I found a workraound in an old email thread at

On your workstation:

  • edit ~/.subversion/config: locate [tunnels] and add the line ssh=~/svnssh
  • create ~/svnssh as in the link:

    /usr/bin/ssh $1 /<ur_bluhost_home_path>/sshsvnserve -t

  • chmod +x ~/svnssh

On your bleuhost account:

  • create ~/sshsvnserve, same content as the link:

    /<ur_bluehost_home_path>/bin/svnserve $*

  • chmod +x ~/sshsvnserve

That's it. The config [tunnels] change modifies the command run by svn when handling the svn+ssh namespace and use ur ~/svnssh script instead. The script invokes ssh and passes in the full path to sshsvnserve on ur bluehost account. And sshsvnserve redirects everything to the full path of svnserve, as u install it. Worked for me, no $PATH required.

share|improve this answer

Set the variable BASH_ENV to '~/.bashrc'.

ssh servername "BASH_ENV='~/.bashrc' which svnserve"

From man bash:

When bash is invoked as an interactive login shell, or as a non-inter‐ active shell with the --login option, it first reads and executes com‐ mands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable.


When an interactive shell that is not a login shell is started, bash reads and executes commands from /etc/bash.bashrc and ~/.bashrc, if these files exist.


When bash is started non-interactively, to run a shell script, for example, it looks for the variable BASH_ENV in the environment, expands its value if it appears there, and uses the expanded value as the name of a file to read and execute.

From man ssh:

Additionally, ssh reads ~/.ssh/environment, and adds lines of the format “VARNAME=value” to the environment if the file exists and users are allowed to change their environment. For more information, see the PermitUserEnvironment option in sshd_config(5).

From man sshd_config:

Specifies whether ~/.ssh/environment and environment= options in ~/.ssh/authorized_keys are processed by sshd(8). The default is “no”. Enabling environment processing may enable users to bypass access restrictions in some configurations using mechanisms such as LD_PRELOAD.

share|improve this answer
@Dennis, yes, this is as I would expect. However, in my case I clearly see that .bashrc is NOT being loaded. Moreover, ~/.ssh/environment is ignored. I can conclude that Bluehost (my server provider) configured it this way, which is very unfortunate. P.S. the line with BASH_ENV doesn't work for me – Eli Bendersky Apr 9 '10 at 11:03

I was able to get ssh to run commands using the remote path by running:

ssh dist@d6 "bash --login -c 'env'"

This loads the remote .profile, etc. Here env can be replaced with what ever command you'd like.

I have authorized keys so didn't need a password to run the command or ssh.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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