So this problem has cost me quite a lot of hours, and the solution was so simple. I don't believe it's the only solution, and it's probably not the solution I needed for my particular situation, but it's a solution that worked.

The core problem, I believe, is that when you ssh into your server, you are generally working from an interactive shell. This means that it pretty much behaves like the terminal emulator you would use on a local machine. If, however, you are running scripts (or any applications, for that matter) on your remote host over SSH, those are executed in a non-interactive shell.

One difference between the two is that {" non-interactive shells don't read data from your configuration files "} like .bashrc . This is usually not a problem, unless you have to customize your $PATH. The $PATH is how the shell
knows where to look for the commands that you enter into it.

On a bare-bones Linux system, the $PATH will typically look something like this:

/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin

Those are the locations in which the shell looks for applications. If you install new applications via your package manager, those should probably suffice. And even if applications reside in different places, your package manager will usually add the new locations to your $PATH. For example, my $PATH looks like this:

/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/opt/android-sdk/platform-tools:/opt/android-sdk/tools:/usr/share/java/apache-ant/bin:/opt/dassault-systemes/draftsight/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl

In order to use Octopress on my server, I also had to add a new location to my $PATH. Octopress depends on the programming language Ruby, which I didn't install using my package manager. Why not? Because {" the developer explicitly stated that version 1.9.2 should be used for his application "}. A bit annoying if you ask me, but as a beginner I didn't want to risk running into otherwise avoidable issues while running Octopress. After all, it powers the blog you know and love ;)

So I installed Ruby using RVM. RVM allows me to have multiple Ruby versions sit next to each other on my system. In order not to conflict with the "stock" Ruby that you may or may not have installed from your distribution's package archives, it installs Ruby in a different path. And thusly we've come full circle.

If you've installed RVM globally (i.e. every user on your system can use it), the path is /usr/local/rvm. If you've installed it only for your user, it's $HOME/.rvm. As per RVM installation instructions, you are supposed to add the following line to your shell configuration file, which checks for the file "rvm" (which contains informations about all the different paths RVM is using) and, if it exists, adds those paths to your $PATH by sourcing said file into your shell configuration file:

[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm"

Note that I have used a singler-user installation of RVM for the example above. Now, this works beautifully, as long as you are working inside an interactive shell. If you check your $PATH with echo $PATH, it will print something like this:

/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/rvm/gems/ruby-1.9.2-p320/bin:/usr/local/rvm/gems/ruby-1.9.2-p320@global/bin:/usr/local/rvm/rubies/ruby-1.9.2-p320/bin:/usr/local/rvm/bin:/usr/local/rvm/scripts/rvm

As you can see, all kinds of RVM related paths have been added. However, if you run the same command from you local machine using ssh user@remotehost echo \$PATH (note that I have added an escape character so it doesn't show your local system's $PATH instead), you get the ol' bare-bones $PATH again. Again, this is because non-interactive shells don't read data from your shell configuration files.

The solution I have come up with is this: In your /etc/ssh/sshd_config, uncomment this line:

PermitUserEnvironment yes

This makes you use a whole different environment (which includes the $PATH) whenever you interact with your server via SSH. You can configure this environment in $HOME/.ssh/environment. By default, you still get the "bare" $PATH, but you can now define a new $PATH which will also be used by commands you run over SSH.

You can probably source the aforementioned "rvm" file somehow, but what I did was just pasting the "complete" list like so:

PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/rvm/gems/ruby-1.9.2-p320/bin:/usr/local/rvm/gems/ruby-1.9.2-p320@global/bin:/usr/local/rvm/rubies/ruby-1.9.2-p320/bin:/usr/local/rvm/bin:/usr/local/rvm/scripts/rvm

For good measure, I also added some other lines from the "rvm" file into environment:

RUBY_VERSION=ruby-1.9.2-p320
GEM_HOME=/usr/local/rvm/gems/ruby-1.9.2-p320 GEM_PATH=/usr/local/rvm/gems/ruby-1.9.2-p320:/usr/local/rvm/gems/ruby-1.9.2-p320@global MY_RUBY_HOME=/usr/local/rvm/rubies/ruby-1.9.2-p320 IRBRC=/usr/local/rvm/rubies/ruby-1.9.2-p320/.irbrc

This might be silly and unnecessary, but oh well. Maybe I will clean it up at some point. Make sure that all of those lines actually include valid paths that exist on your system.

General annotation: I've tried to keep this guide Linux distribution agnostic. It might even be useful for Mac OS users. However, I have made the assumption that your shell is Bash. Things might work slightly differently in other shells.

Update: Quinn tells me that Mac OS X has been capable of using Bash in its terminal app at least from version 10.6 onwards. He also notes that most of this tutorial, with the exception of the actual installation of RVM, should well be applicable to OS X. The SSH configuration is located somewhere else, though: You can find it at /etc/sshd_config.