java -jar over ssh

disturbed1 · 07-21-2009, 11:53 AM

I've found the recent need to run a java jar application over ssh. X is forwarded and works fine. When logged in as a normal user over ssh the java command simply is not found. The same user can run java applications locally.

Can someone tell me which config file I need to alter? Or would I have to recompile openssh and add /usr/lib64/java to --with-default-path=?

Yes I know this may not be secure. In my case ssh is only forwarded on the local network, all connections outside of the LAN are blocked.

jhcaiced · 07-21-2009, 12:35 PM

Sorry, I cannot understand what are you trying to do...
Trying to guess:

- When you has a remote session open via ssh, you can do X forwarding
fine, so any java application with a graphical interface correctly
installed on the remote machine should work fine also.
- The "java not found" seems to be a problem with your path
on the remote machine, why don't try to specify it when
starting the application.
- I don't see how recompiling openssh would help, the issues seems
to be different.

Hope it helps but more information should be useful.

Best regards,

disturbed1 · 07-21-2009, 12:48 PM

I don't think you understand the problem

Slackware uses different paths than Ubuntu and CentOS. Java has a predefined path variable, that is not defined in openssh by default. I was hoping there was a config file to alter, and not having to recompile openssh.

LNXman · 07-21-2009, 02:41 PM

Quote:

Originally Posted by disturbed1

I've found the recent need to run a java jar application over ssh. X is forwarded and works fine. When logged in as a normal user over ssh the java command simply is not found. The same user can run java applications locally.

I don't have much detail on how your environment is configured, but have you tried to see what environment settings are available when your target user ssh-es onto the remote server?

One quick test to check out the environment is to execute the printenv command on the remote server as the user which you want to use to run your java program:

ssh <user>@<server> printenv

The output of the command should give you enough information as to whether your remote java command can be found, and whether your environment is set up correctly for the user running the remote command.

To quickly test the remote java execution, you can just run the java -version command on the remote machine:

ssh <user>@<server> java -version

Hope this tid-bit helps,

GL

disturbed1 · 07-21-2009, 08:21 PM

Quote:

Originally Posted by LNXman

I don't have much detail on how your environment is configured, but have you tried to see what environment settings are available when your target user ssh-es onto the remote server?

ssh <user>@<server> printenv

ssh <user>@<server> java -version

Hope this tid-bit helps,

GL

The environment is cofigured correctly, as it's just a stock, non mucked with Slackware setup.

At the local machine

Code:

bash-3.1$ id
uid=1000(keith) gid=100(users) groups=11(floppy),17(audio),18(video),19(cdrom),83(plugdev),100(users)
bash-3.1$ java -version
java version "1.6.0_14"
Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
Java HotSpot(TM) 64-Bit Server VM (build 14.0-b16, mixed mode)

Via ssh

Code:

bash-3.1$ id
uid=1000(keith) gid=100(users) groups=11(floppy),17(audio),18(video),19(cdrom),83(plugdev),100(users)
bash-3.1$ java -version
bash: java: command not found
bash-3.1$ /usr/lib64/java/bin/java -version
java version "1.6.0_14"
Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
Java HotSpot(TM) 64-Bit Server VM (build 14.0-b16, mixed mode)

At local machine

Code:

printenv |grep java
MANPATH=/usr/local/man:/usr/man:/usr/lib64/java/man:/usr/share/texmf/man
PATH=/usr/local/bin:/usr/bin:/bin:/usr/games:/usr/lib64/java/bin:/usr/lib64/kde4/libexec:/opt/kde3/lib64/qt3/bin:/opt/kde3/bin:/usr/lib64/qt/bin:/usr/share/texmf/bin:.
JAVA_HOME=/usr/lib64/java

Via ssh

Code:

bash-3.1$ printenv | grep java
bash-3.1$

bash-3.1$ printenv | grep PATH
PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin

Notice via ssh there is no /usr/lib64/java/bin.

Openssh on Slackware is compiled with this option

Code:

--with-default-path=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin

Tired of mucking around, I simply added the correct $JAVA_HOME path to openssh's configure, recompiled, and all is good now

.

piete · 07-22-2009, 08:45 AM

This problem intrigued me, and although it's been worked around, it doesn't feel like a neat solution. To the OP: feel free to disregard the following, I'm just exercising the grey matter more than anything else. If you feel like playing hunt the bug with me, I look forward to it

I first thought about getting the output of ls -l /etc/profile.d and ls -l /etc/profile, which would show me what was executable and what was not, and since Java is added to the PATH from /etc/profile.d/jre.{sh,csh} (or jdk.{sh,csh}), this seemed like a good start.

However, we know that logging in locally works, so clearly /etc/profile is working and I'd postulate that jre.sh is executable and in the right place. If there is no jre.sh and the path variables are set elsewhere, then that could be an issue.

So what's the difference between the two setups?

Assuming jre.sh is fine, the another difference is the shell invocation (find out more about shell invocation from man bash). If you're using anything but a login shell, you won't get the full environment you're expecting.

Why would you not have a login shell? Hmm, don't know, so let's have a look around man ssh and see what ssh says.

Quote:

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).

Well, that would be a neat workaround that wouldn't mean recompiling openssh at least, and has given me another link.

Let's check the sshd_config file and see what's set by default:

Code:

#UseLogin no
...
#PermitUserEnvironment no

Well, I'd say that uncommenting those would reverse the default settings, so it looks like, by default, you're using a login shell and have you permissions to change the environment on login.

So, what's not installed, corrupted or has been tweaked with to stop a stock install from working? My first query would have to be, where has java come from?

Like I say, feel free to disregard, but I'm interested in what could cause such a problem!

- Piete.

mrclisdue · 07-22-2009, 09:43 AM

Actually, according to sshd_config:

Code:

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.

Hence, by default, OP doesn't have a login shell, nor permission to change the environment on login. One would have to uncomment the lines, and change the "No" to a "Yes".

No?

cheers,

piete · 07-22-2009, 09:54 AM

No ... yes ... no ... how many non-double negatives does it not take for an engineer to not change a lightbulb if it hasn't blown?

I'm with you now, yes, and I would concur with that. Note to self, use a pager to read config files back, not cat ...

So no login shell, no permission to change the environment, and yet my sshd is the same, but my path includes java. Still unsure on where java has come from or what non-default settings are floating around.

Could be worth setting those variables explicitly, in that totally scientific 'just to see what happens' way.

disturbed1 · 07-22-2009, 10:35 PM

Quote:

Originally Posted by piete

No ... yes ... no ... how many non-double negatives does it not take for an engineer to not change a lightbulb if it hasn't blown?

I'm with you now, yes, and I would concur with that. Note to self, use a pager to read config files back, not cat ...

So no login shell, no permission to change the environment, and yet my sshd is the same, but my path includes java. Still unsure on where java has come from or what non-default settings are floating around.

Could be worth setting those variables explicitly, in that totally scientific 'just to see what happens' way.

I had to read that post 4 or 5 times to get through my thick skull.

Code:

#UseLogin no

I'm guessing, from your posts, if I had changed sshd_config to UseLogin from the default no to yes, ssh would use the login command, and process the profile? By not using the login command, ssh does not read profile, and falls back to the defaults that were passed to the openssh configure?

In the long run, recompiling ssh was simple enough. Even though, myself personally, would have either tab-completed to /usr/lib64/java/bin/java, or created a simple 2 line shell script to launch the application - This wasn't my issue. It was for the woman I sleep next to at night. And we all know the things we have to do to please those creatures

piete · 07-23-2009, 10:15 AM

Quote:

I'm guessing, from your posts, if I had changed sshd_config to UseLogin from the default no to yes, ssh would use the login command, and process the profile? By not using the login command, ssh does not read profile, and falls back to the defaults that were passed to the openssh configure?

Yeah, that seems to be the consensus. What doesn't make any sense is that everyone elses UseLogin is set to no and theirs works. If you ever find out what the true root cause of this issue is, do let us know

Quote:

This wasn't my issue. It was for the woman I sleep next to at night.

Ah, yes. Glad you got solved in a timely manner!

disturbed1 · 07-23-2009, 11:32 AM

Quote:

Originally Posted by piete

Yeah, that seems to be the consensus. What doesn't make any sense is that everyone elses UseLogin is set to no and theirs works. If you ever find out what the true root cause of this issue is, do let us know

I believe it's the Xming ssh client she's using on that PC (has Windows XP). I didn't see an option to uselogin or anything similar. Using ssh from a couple of different Slackware PCs (-current, 12.1, and 12.2) all result in java being in the path. Using Putty directly, also results in java being in the path.

Changing sshd_config to Uselogin Yes (stop/start ssh

) results in Xming not being able to connect.

The PC is not actually ours, but a loaner while we wait on her laptop to be delivered. Gotta love warranties