You're expecting the shell to source ~/.bashrc, so I assume the shell is Bash.
Twist number 1: SSH server passes the shell code to a non-interactive shell. Non-interactive Bash does not read ~/.bashrc.
Twist number 2: Bash attempts to determine when it is being run with its standard input connected to a network connection, as when executed by a SSH server. If bash determines it is being run in this fashion, it does read and execute commands from ~/.bashrc.
Twist number 3: In many distros (including Ubuntu) the default (skeletal) ~/.bashrc starts with code that returns if the shell is non-interactive. In effect the rest of the file is not sourced.
I guess in your case the relevant environment variables are defined after this piece of code. The code may look like this:
# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac
A straightforward solution is to move the assignments so they are before this code. If you'd like to move commands that do more (e.g. echo something, run something) then be very careful because you may break remote file transfers. Read Why does bashrc check whether the current shell is interactive? If it's about variables only then you should be safe.
In general the environment should be defined in ~/.profile rather than in ~/.bashrc, but if you moved the assignments to ~/.profile then you would experience this: ~/.profile is not loaded when using SSH. It's not unreasonable to have them in ~/.bashrc then.
Alternatively you can place them in a separate file, e.g. ~/.special_env, and source the file from ~/.bashrc or ~/.profile or whatever. The advantage is you can source the file on demand regardless of quirks and twists:
ssh -i keyfile [email protected] '. ~/.special_env; sh -v /opt/dir/script'
