I tried to XForward netbeans to my laptop, using the following code:

# This does not work
$ ssh [email protected] -Y netbeans
which: no javac in (/usr/bin:/bin:/usr/sbin:/sbin)
which: no java in (/usr/bin:/bin:/usr/sbin:/sbin)
Cannot find java. Please use the --jdkhome switch.

That did not work, but this did:

# This works
$ ssh [email protected] -Y
user@home $ netbeans

My questions:

  • Why does the first method fail?
  • How can I make the first method work?

2 Answers 2


ssh example.com somecommand doesn't read your ~/.profile; somecommand is executed directly by the ssh daemon. When you don't specify a command, the ssh daemon invokes your login shell, which reads your ~/.profile. (Substitute ~/.bash_profile, ~/.zprofile or ~/.login depending on your login shell.)

There are a few ways to set environment variables for a non-interactive command, but they all require a setting in the server configuration which is typically off by default. Assuming a recent enough OpenSSH on both sides:

  • You can have environment variables sent from the client to the server with the SendEnv directive in ~/.ssh/config. The specific environment variable must be enabled with an AcceptEnv directive in the server configuration.

  • You can set environment variables through ~/.ssh/environment on the server side. This must be enabled in the server configuration with the PermitUserEnvironment directive.

  • Assuming you use key-based authentication, you can also set per-origin variables in ~/.ssh/authorized_keys: add environment="FOO=bar" at the beginning of the relevant line. Again, you need the PermitUserEnvironment directive in the server configuration.

If you can't or don't want to change the server configuration, you'll have to write the full path to the remote command, or explicitly source your .profile in the remote command.

ssh [email protected] -Y '. ~/.profile; netbeans'
ssh [email protected] -Y '/path/to/netbeans'

From the ssh(1) manual page (my emphasis):

If command is specified, it is executed on the remote host instead of a login shell.

In other words, it doesn't make a "login" on the remote system when you pass a command to ssh. It runs your shell in non-login, non-interactive mode, which causes a different set of initialization files to run.

You should check where your PATH variable is being set, and move that to the appropriate file. If your shell is bash, for example, you should use .bashrc, and not .bash_profile.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .