MacOS – Setting the system-wide PATH environment variable in Mavericks

The issue is that you are not running in your environment so any changes to ~/.bash_profile will have no effect on the command. It will be visible to other processes

sudo runs as another user - in this case root as you have not provided a -u username parameter. Thus you need to change the root environment to make JAVA_HOME visible to the run.sh command

The correct file, prior to Mavericks, was ~/.MacOSX/environment.plist. This is no longer supported.

In Darwin, and therefore in Mac OS X, the proper place to set these is in /etc/launchd.conf to apply to all processes; if relating to user shells specifically, use the appropriate shell files instead, depending on the shell in question. See the launchd.conf and launchctl man pages for more.

That said...

If you're goal is specifically to see these applied for ssh sessions then you need to be aware that ssh, for security reasons, doesn't apply environment variables in this manner. In fact a ssh session normally receives a much more restrictive set of environment variables from the OS as it's not what is known as a "login" or "interactive" shell, it's classified as an "non-interactive" shell. (See man bash for more on shell types.) The way ssh handles environment variables is well covered in the ssh/sshd docs and man pages.

For ssh -- which is it's own shell, akin to bash -- environment variables for the session are stored in ~/.ssh/environment as the per-user equivalent of setting these for bash or csh, etc in their relevant launch files. This is probably where you want to set your ENV variables for your user ssh sessions, though you don't detail why you're looking to assign ENVs globally in your original post, which would have been helpful in providing a solution. I'd suggest you set them explicitly on a user per user basis to maintain proper security based on each respective account following the least restrictive privilege/attribute best practice.

If for some reason you wish to ignore he security implications of this, then set PermitUserEnvironment in your ssh configs. Note that this is disabled if UseLogin is enabled. IMPORTANT: Realize that this means that user accounts set to use /bin/false as their shell - the typical method for disabling a user account - can now potentially get around this restriction and could now become active, which is dangerous. Many accounts are set to use /bin/false as their shell as a security expectation.

Bottom line is you shouldn't be doing this globally and expecting ssh to propagate ENV for security reasons. Your question is, effectively, purposely asking how to defeat several mechanisms that exist for security reasons.