I want to control a remote system in Java via SSH using JSCH.
The front end is a simple button GUI which triggers the execution of a command.
Some of the controls are time critical, there should be no big delay between button press and command execution.
My problem:
Every time a new channel is opened, the back-end needs about 8 seconds to initialize until the command is executed. (The back-end interface is implemented with RBSH afaik)
If I run a normal session via a console client, everything runs fine without bigger delays.
My question:
Is there a way to initialize a channel to execute some commands and read the output(and only the command output) back sequentially?
I already figured out that session.openChannel("shell") could give the desired functionality, but I cant figure out how to do that properly.
EDIT: I'm not tied to JSCH. If there's another library which can do that, I'm also open for that
You want an "exec" channel rather than a "shell" channel. SCP uses an exec channel, so look at one of the SCP examples or one of the SCP libraries on the Internet.
Alternately, if you control the remote server, you could define a "subsystem" for the command that you want to run, and run it through a subsystem channel. The big difference between an exec channel and a subsystem is who specifies the command to be executed. An exec channel will execute a command provided by the client. With a subsystem, the client just requests the subsystem by name, and the server runs the correct command (or provides the service in some other way). SFTP uses a subsystem called "sftp-server", so you could look at how Jsch's SFTP classes are implemented.
Related
Currently I have slow starting java service in systemd which takes about 60 seconds until it opens its HTTP port and serves other clients.
Another client service expects this service to be available (is a client of the this service), otherwise it dies after a certain retry. It also started with systemd. This is to be clear also a service. But uses the former like database.
Can I configure systemd to wait until the first service has made his socket available? (something like if the socket is actually listens , then the second client service should start).
Initialization Process Requires Forking
systemd waits for a daemon to initialize itself if the daemon forks. In your situation, that's pretty much the only way you have to do this.
The daemon offering the HTTP service must do all of its initialization in the main thread, once that initialization is done and the socket is listening for connections, it will fork(). The main process then exits. At that point systemd knows that your process was successfully initialized (exit 0) or not (exit 1).
Such a service receives the Type=... value of forking as follow:
[Service]
Type=forking
...
Note: If you are writing new code, consider not using fork. systemd already creates a new process for you so you do not have to fork. That was an old System V boot requirement for services.
"Requires" will make sure the process waits
The other services have to wait so they have to require the first to be started. Say your first service is called A, you would have a Requires like this:
[Unit]
...
Requires=A
...
Program with Patience in Mind
Of course, there is always another way which is for the other services to know to be patient. That means try to connect to the HTTP port, if it fails, sleep for a bit (in your case, 1 or 2 seconds would be just fine) then try again, until it works.
I have developed both methods and they both work very well.
Note: A powerful aspect to this method, if service A gets restarted, you'd get a new socket. This server can then auto-reconnect to the new socket when it detects that the old one goes down. This means you don't have to restart the other services when restarting service A. I like this method, but it's a bit more work to make sure it's all properly implemented.
Use the systemd Auto-Restart Feature?
Another way, maybe, would be to use the restart on failure. So if the child attempts to connect to that HTTP service and fails, it should fail, right? systemd can automatically restart your process over and over again until it succeeds. It's sucky, but if you have no control over the code of those daemons, it's probably the easiest way.
[Service]
...
Restart=on-failure
RestartSec=10
#SuccessExitStatus=3 7 # if success is not always just 0
...
This example waits 10 seconds after a failure before attempting to restart.
Hack (last resort, not recommended)
You could attempt a hack, although I do not ever recommend such things because something could happen that breaks such... in the services, change the files so that they have a sleep 60 then start the main process. For that, just write a script like so:
#!/bin/sh
sleep 60
"$#"
Then in the .service files, call that script as in:
ExecStart=/path/to/script /path/to/service args to service
This will run the script instead of directly your code. The script will first sleep for 60 seconds and then try to run your service. So if for some reason this time the HTTP service takes 90 seconds... it will still fail.
Still, this can be useful to know since that script could do all sorts of things, such as use the nc tool to probe the port before actually starting the service process. You could even write your own probing tool.
#!/bin/sh
while true
do
sleep 1
if probe
then
break
fi
done
"$#"
However, notice that such a loop is blocking until probe returns with exit code 0.
You have several options here.
Use a socket unit
The most elegant solution is to let systemd manage the socket for you. If you control the source code of the Java service, change it to use System.inheritedChannel() instead of allocating its own socket, and then use systemd units like this:
# example.socket
[Socket]
ListenStream=%t/example
[Install]
WantedBy=sockets.target
# example.service
[Service]
ExecStart=/usr/bin/java ...
StandardInput=socket
StandardOutput=socket
StandardError=journal
systemd will create the socket immediately (%t is the runtime directory, so in a system unit, the socket will be /run/example), and start the service as soon as the first connection attempt is made. (If you want the service to be started unconditionally, add an Install section to it as well, with WantedBy=multi-user.target.) When your client program connects to the socket, it will be queued by the kernel and block until the server is ready to accept connections on the socket. One additional benefit from this is that you can restart the service without any downtime on the socket – connection attempts will be queued until the restarted service is ready to accept connections again.
Make the service signal readiness to systemd
Alternatively, you can set up the service so that it signals to systemd when it is ready, and order the client after it. (Note that this requires After=example.service, not just Requires=example.service! Dependencies and ordering are orthogonal – without After=, both will be started in parallel.) There are two main service types that might make this possible:
Type=forking: systemd will consider the service to be ready as soon as the main program exits. Since you can’t fork in Java, I think you would have to write a small shell script which starts the server in the background and then waits until the socket is available (while ! test -S /run/example; do sleep 1s; done). Once the script exits, the service is considered ready.
Type=notify: systemd will wait for a message from the service before it is considered ready. Ideally, the message should be sent from the service PID itself: check if you can call the sd_notify function from libsystemd via JNI/JNA/whatever (specifically, sd_notify(0, "READY=1")). If that’s not possible, you can use the systemd-notify command-line tool (--ready option), but then you need to set NotifyAccess=all in the service unit (by default, only the main process may send notifications), and even then it likely will not work (systemd needs to process the message before systemd-notify exits, otherwise it will not be able to verify which cgroup the message came from).
I have a Java Program that needs to invoke a URL, that is reachable only after a VPN connection has been established (to a remote VPN host). The program runs on a Linux box.
Therefore, I need to be able to start/stop the VPN connection as-needed (essentially I do not need it 24 hours).
What is the best way for this:
Can i create a VPN Connection programatically in Java? Is it even possible?
Can i install VPN Client software on Linux Machine, and then via a shell script (which i will invoke via Java), start/stop the VPN Client Connection whenever needed. Is this viable or better solution?
Yes, you can initiate VPN connection from a program (it does not matter which programming language) by running appropriate administration command. The exact administration command is distribution or even installation specific.
Normally a VPN connection (provided by OpenVPN) will be started by (shell) command /etc/init.d/openvpn start vpnname or a wrapper script (RedHat-derivatives have one, other distributions may not). That command has to be executed as root, so you additionally need to prefix it with sudo and configure sudo so that the user running the application can run that command.
Since the command is specific to the installation, you'll need to make it configurable (and possibly ship default config appropriate for distributions you use).
There are other, mutually incompatible VPN implementations too. Each will have different command to start it, but each will have such command, so the implementation should be able to start any of them given appropriate configuration.
Note, that VPN generally may require password for starting. If it does, the password either has to be saved on the client, or you'll additionally need to provide means for user to enter it. How it would be passed is again VPN, distribution and possibly installation-specific.
I am trying to make a terminal emulator in Java. The java program will accept the commands from user, and show its output to them. I can emulate simple commands like 'ls', but I don't know how to handle commands like 'cd'. This is because, I am using exec() method for executing terminal commands. So, all the commands are executed at current directory. The commands like 'cd ..' are executed, but then they have no persistent effect, because each command is separately executed by exec().
Any Ideas How I can emulate a whole session??
If you are executing commands with exec(), you are not writing a terminal emulator; you are writing a shell. In that case, you will need to keep track of things the shell keeps track of, like environment variables and working directory.
If you really want to write a terminal emulator, you would be talking to a shell process through a pseudo-terminal. Then your program would just be keeping track of the things a terminal keeps track of, like the line state and what appears on the screen.
Working with a pseudo-terminal from Java will be a little tricky, because most of the documentation assumes you are using a C api. man pty should get you started. Your Java process will have to open the master side of the pseudo-terminal with FileStream objects. I'm not sure there is a way within Java to get a child process to open the slave side of the pseudo-terminal; you might have to invoke a shell command with exec() that starts another shell command with standard input/output/error redirected to the slave side of the pseudo terminal.
JSch is a pure Java implementation of SSH2.
JSch allows you to connect to an sshd server and use port forwarding, X11 forwarding, file transfer, etc., and you can integrate its functionality into your own Java programs.
http://www.jcraft.com/jsch/
You should really give a try to Ganymed.
Ganymed SSH-2 for Java is a library which implements the SSH-2
protocol in pure Java (tested on J2SE 1.4.2 and 5.0). It allows one to
connect to SSH servers from within Java programs. It supports SSH
sessions (remote command execution and shell access), local and remote
port forwarding, local stream forwarding, X11 forwarding, SCP and
SFTP.
http://www.ganymed.ethz.ch/ssh2/
Ganymed along with apache FTP client you can also download and upload files.
Also there is a inbuilt example code for terminal emulation in Ganymed.
The following is a link to a project which is did using Ganymed along with apache FTP client.
GITHUB
Happy Coding!!
Suppose I launch a Java application:
java -cp whatever.jar com.example.Start
Process launches ok and keeps running with PID 1314.
Now I would like the system to fire a method by users request.
How can I use bash to signal the running PID and have it fire a method?
My thought is to have bash echo data to the Java processes via a named pipe, which I'm pretty sure Java has support for.
To communicate with a Java process, you would normally use RMI from another process (this could be in the same JAR)
However, if you want a pure bash/unix utilities solution, you could have the application listen on a port for commands and send back responses. This means you could use plain telnet to send commands and get output. One example of this is to use a http server with wget or you could have a simple socket based solution.
We have some applications that sometimes get into a bad state, but only in production (of course!). While taking a heap dump can help to gather state information, it's often easier to use a remote debugger. Setting this up is easy -- one need only add this to his command line:
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=PORT
There seems to be no available security mechanism, so turning on debugging in production would effectively allow arbitrary code execution (via hotswap).
We have a mix of 1.4.2 and 1.5 Sun JVMs running on Solaris 9 and Linux (Redhat Enterprise 4). How can we enable secure debugging? Any other ways to achieve our goal of production server inspection?
Update: For JDK 1.5+ JVMs, one can specify an interface and port to which the debugger should bind. So, KarlP's suggestion of binding to loopback and just using a SSH tunnel to a local developer box should work given SSH is set up properly on the servers.
However, it seems that JDK1.4x does not allow an interface to be specified for the debug port. So, we can either block access to the debug port somewhere in the network or do some system-specific blocking in the OS itself (IPChains as Jared suggested, etc.)?
Update #2: This is a hack that will let us limit our risk, even on 1.4.2 JVMs:
Command line params:
-Xdebug
-Xrunjdwp:
transport=dt_socket,
server=y,
suspend=n,
address=9001,
onthrow=com.whatever.TurnOnDebuggerException,
launch=nothing
Java Code to turn on debugger:
try {
throw new TurnOnDebuggerException();
} catch (TurnOnDebugger td) {
//Nothing
}
TurnOnDebuggerException can be any exception guaranteed not to be thrown anywhere else.
I tested this on a Windows box to prove that (1) the debugger port does not receive connections initially, and (2) throwing the TurnOnDebugger exception as shown above causes the debugger to come alive. The launch parameter was required (at least on JDK1.4.2), but a garbage value was handled gracefully by the JVM.
We're planning on making a small servlet that, behind appropriate security, can allow us to turn on the debugger. Of course, one can't turn it off afterward, and the debugger still listens promiscuously once its on. But, these are limitations we're willing to accept as debugging of a production system will always result in a restart afterward.
Update #3: I ended up writing three classes: (1) TurnOnDebuggerException, a plain 'ol Java exception, (2) DebuggerPoller, a background thread the checks for the existence of a specified file on the filesystem, and (3) DebuggerMainWrapper, a class that kicks off the polling thread and then reflectively calls the main method of another specified class.
This is how its used:
Replace your "main" class with DebuggerMainWrapper in your start-up scripts
Add two system (-D) params, one specifying the real main class, and the other specifying a file on the filesystem.
Configure the debugger on the command line with the onthrow=com.whatever.TurnOnDebuggerException part added
Add a jar with the three classes mentioned above to the classpath.
Now, when you start up your JVM everything is the same except that a background poller thread is started. Presuming that the file (ours is called TurnOnDebugger) doesn't initially exist, the poller checks for it every N seconds. When the poller first notices it, it throws and immediately catches the TurnOnDebuggerException. Then, the agent is kicked off.
You can't turn it back off, and the machine is not terribly secure when its on. On the upside, I don't think the debugger allows for multiple simultaneous connections, so maintaining a debugging connection is your best defense. We chose the file notification method because it allowed us to piggyback off of our existing Unix authen/author by specifying the trigger file in a directory where only the proper uses have rights. You could easily build a little war file that achieved the same purpose via a socket connection. Of course, since we can't turn off the debugger, we'll only use it to gather data before killing off a sick application. If anyone wants this code, please let me know. However, it will only take you a few minutes to throw it together yourself.
If you use SSH you can allow tunneling and tunnel a port to your local host. No development required, all done using sshd, ssh and/or putty.
The debug socket on your java server can be set up on the local interface 127.0.0.1.
You're absolutely right: the Java Debugging API is inherently insecure. You can, however, limit it to UNIX domain sockets, and write a proxy with SSL/SSH to let you have authenticated and encrypted external connections that are then proxied into the UNIX domain socket. That at least reduces your exposure to someone who can get a process into the server, or someone who can crack your SSL.
Export information/services into JMX and then use RMI+SSL to access it remotely. Your situation is what JMX is designed for (the M stands for Management).
Good question.
I'm not aware of any built-in ability to encrypt connections to the debugging port.
There may be a much better/easier solution, but I would do the following:
Put the production machine behind a firewall that blocks access to the debugging port(s).
Run a proxy process on the host itself that connects to the port, and encrypts the input and output from the socket.
Run a proxy client on the debugging workstation that also encrypts/decrypts the input. Have this connect to the server proxy. Communication between them would be encrypted.
Connect your debugger to the proxy client.