I'm currently trying to create an automated test using Java that runs some commands in a remote server the problem is that this remote server has a firewall. Manually I can ssh into the first server (firewall) using putty. Then I enter the details to the Server I wish to execute the commands. I've seen some article with code that mention how to use java code (jsch.jar) that I can ssh into a remote client but I haven't found a good enough explanation when a firewall is present. Can someone give me an explanation of what I should be trying to do and with some code snippet if possible
Not a complete answer, just an idea.
OpenSSH has a feature called ProxyCommand. It allows one to automatically issue a command on a target system, presumably another ssh.
So I have several entries of this sort in my .ssh/config:
Host the.private.host.behind.firewall.net
Hostname 10.0.100.106
User username_on_the_private_host
Compression yes
ProxyCommand ssh the.firewall.net nc -q 1 %h %p
Now I can issue ssh the.private.host.behind.firewall.net and first get to the SSH authentication on the.firewall.net, and then to the second authentication on the target host.
Likely Java implements SSH protocol on its own, but perhaps you could create a construction like this one.
Related
So, I want to create my own SSH Client, not just sending commands but a full on ssh client for me to use like you would use PuTTy or mobaxterm, can someone here point me in the right direction.
Things I tried / thought of:
- Using Jsch to send and execute commands (If its possible I would love to know if this is able to be done without using Jsch).
SSH is a protocol that is defined to run on top of TCP, and you can make TCP connections in java using the java.net.Socket class.
So, yes, it can be done.
You'd have to implement the protocol yourself (or use JSch to do it, but given that all these tools already exist, and it's security, where in general relying on widely used tools is orders of magnitude more intelligent than relying on hand-written stuff, given that a security bug is very hard to test for – I assume this is some sort of exercise in sheer dogged arrogance, or, more likely, a learning exercise, which'd mean that you wouldn't want to use jsch here).
ssh works by sending any number of streams across the network, encrypted. By default, there is one stream (a two-way stream), with the user's shell being on one end (so, the /bin/bash executable, for example), and a terminal (where what you type forms the input, and any output is echoed to the terminal window) on the other.
ssh does NOT wait for you type a command then run it; that's /bin/bash doing this. This is basic linux info and has no direct bearing on ssh (the protocol), that's just what you're used to, because sshd (the linux executable that forms an ssh server) by default hooks your terminal up to the target server's shell executable. Usually bash.
Given that you know nothing of this, this sounds like a project that's a bit too far fetched as a starter experiment, but I'm going by incomplete information to make this assessment.
I'd start by making a trivial telnet client and server. telnet is at this point extremely outdated but it is basically ssh without the multiplexing of streams nor the encryption. If you can't write a telnet client, you can't write an ssh client either. And you can still start telnet servers on linux machines for testing purposes.
Once you've got that down, start figuring out the crypto and the multiplexing*.
*) With ssh you can, whilst having a shell open, also port forward and such; check out the -R and -L and -D options in standard ssh. Each such option allows for another stream to be sent along. (whilst you're sending shell commands and seeing their results, at the same time, over the same ssh connection, you are, say, sending a print job to a printer in the network of the other machine). Sending multiple streams through a single connection is called 'multiplexing', and it is part of the ssh specification.
We are implementing an university project: a car-pooling service in Java.
We need to solve a problem linked "how to manage a postgres server":
the PostgreSQL Database is configured in a lab server called "golem" (130.136.4.sth) reachable only through terminals in the same subnet (130.136.4.0).
We have four account (ours) through we can establish a ssh connection to an host.
Is it possible to make SQL queries through SSH towards Postgres DB in JAVA?
Thank you :)
Davide
If this is just for development, you can use ssh port forwarding to access the database as if it was installed locally. How port forwarding is enabled depends on the client software you use, openssh for example has a command line switch for it (-L):
ssh user#host -L localport:remotehost:remoteport
This command would make the remoteport on remotehost, though accessible only through host, available on localport on your computer.
Take a look at the other suggested answers as they seem easier to accomplish what you need.
However, if you really need to implement the command submission with Java for your lab assignment, you can take a look at the JSch (Java Secure Channel) library found here: http://www.jcraft.com/jsch/ Examples are here http://www.jcraft.com/jsch/examples/
With it you can submit ssh commands and perform any kind of operation via a Java API
If you run "ssh" followed by any command that command gets executed on the remote host. So you should be able to run pre-baked queries in batch mode via ssh.
Consider doing key-gen and key exchanges to enable passwordless ssh execution.
Example (this just dumps a directory listing to your terminal):
ssh me#mybox ls
Scenario
I'm in a Java project where we have to communicate with the CLIs of other machines. Unfortunately, we can't connect to these other machines directly and another bad luck is that they only support telnet. So we have the following setup, which is carved in stone (of course):
application <---- telnet or ssh ----> gateway <---- telnet ----> machine_001
(10.0.0.1) (192.168.1.1) (192.168.2.1)
(192.168.2.2)
( ... )
It's possible to connect via SSH or telnet to the gateway manually (e.g. using PuTTY), telnet from this shell to one of the machines and work with its CLI. As we want the communication to happen automatically, the application must be able to talk to the machines by itself; so I need a programmatic solution.
What I've tried so far
After some research on the internet I've found a library called JSch which looked promising, but I've encountered an evil problem. When the applications connects to the gateway, the telnet command and therefore the whole CLI of the target machine is one single command from application's viewpoint. So I'd have to struggle with a non-terminating InputStream, unsynchronized OutputStream and Threads if necessary.
The next try was to establish a SSH tunnel from L127.0.0.1:1234 to 192.168.2.1:23 (via the gateway), but with this configuration it's not possible to telnet to 127.0.0.1:1234 (neither programmatically nor manually).
The actual question
How can I get my application to talk to the machines via the gateway using telnet?
I'm writing a program in Java using the sockets to communicate with a Telnet server which allows the users to access the file directory in an UNIX OS.
When using Putty to communicate with this server, it prompts me for my username and password, but using my sockets there is nothing from the server except for a string which states that it uses SSH 2.0 - I think.
I'm sure that this has to do with the Telnet protocol, but how do I get the server to ask me for my username and password. What set of commands would I need to give the server in order to access the file directory in an UNIX environment?
Correction:
I figured that it's actually using SSH on port 22. It can be accessed using Putty or Microsoft Windows' Telnet program, but it doesn't actually use the Telnet protocol but the SSH protocol.
SSH isn't telnet. SSH is a protocol that is a lot like telnet, but is encrypted and has a slew of other features. So it looks like youre expecting a plain-text exchange, but what you're getting is the ssh protocol trying to do a handshake.
Telnet runs on port 23, SSH on 22. I imagine you want to use 23. Note: Telnet is old and unencrypetd and dangerous to use over the internet (unless youre going over a VPN or something that encrypts the session).
There is really nothing to the Telnet protocol for most uses...see this page for details. If the server on the other end is trying to negotiate a SSL connection, which is by far the most likely thing these days, try using a java.net.ssl.SSLSocket instead of a bare TCP socket.
Once you negotiate the connection (see the docs linked above) you should essentially print UNIX CLI commands to the socket and read (& parse) the results. If you just want to access files, maybe use FTP instead. Most modern servers are going to support SFTP.
Edit
With a little poking I found that using SSLSocket directly to connect to a SSH server is cumbersome at best because SSH has its own protocol. You probably don't want to reinvent the wheel on that one. Check out the answers to this question for some pure Java SSH client libraries. You can probably use at least one of these to solve your problem more directly than sending text commands over SSH.
Would it be a telnet server, it would be simple.
But what you have is a ssh server, and that is good as it is. telnet is heavily deprecated, as it is not encrypted.
You now have two options: Either use a ssh library or access the ssh command line client (or under Windows: the plink program) via its stdio.
I'm trying to ssh into ubuntu using exec, but for some reason when I execute from the code I get the error
port 22: Connection refused
In the code I use concat to put the strings together, but I know they're put together properly because I print them out and if I copy and paste them into the command line then it will ssh properly.
My code tries:
p1= Runtime.getRuntime().exec(run1);
p1.waitfor();
where
run1 = "ssh -o StrictHostKeyChecking=no -v -i key " + "ubuntu#"+ DNS + " sudo mke2fs -F -j "+device;
Any ideas?
You are initiating the connection, so for it to be refused it means that the machine you are attempting to ssh into is denying you ssh access.
Log into that machine by whatever means you have and verify that the ssh server is running. If it is, then verify that the firewall is not blocking port 22; because, sometimes the ssh server is running but the firewall won't allow network access to the ssh server due to a port blocking rule.
--- Edited after question in comments ---
Is there a difference between ssh in the command line and using exec? Because I can
connect to the server through the command line, which I assume is still using port 22.
So if I can ssh that way does that mean port 22 is working?
There are a few possibilities. Java comes with a Security Manager which only serves to deny programs access to machine resources. This is why it is possible to safely run applet code, which is downloaded from remote servers, as the Security Manager denies permission to access the hard drive or make connections to other machines. In the applet sandbox, it does allow connections back to the originating web server (to download more code and images).
However, the lack of a security exception directs the suspicion away from the Security Manager. The fact that the message uses the words "Connection refused" is a strong indicator that the SSH server you are connecting to won't accept a connection from you.
Perhaps by operating on the command line, the ssh command is using a different environment or configuration. I would see if the command is aliased, of if the ssh connection makes some assumption about key pairs. If nothing seems to be out of line with the command, I would check that your program is connection with ssh version 2 (version 1 is not allowed by many due to a security hole).
Then I would also hunt around for possible differences in name resolution. You might be resolving the hostname in the command line differently than you are resolving it from the Java program. This could mean that the Java program is attempting connection to a different machine, one which doesn't have a secure shell server running.
Either way, it seems that you'll have to do a bit of debugging to isolate if it is a true coding problem or an environmental issue.
If you are getting Connection refused, the SSHD is not running or you are being blocked by Firewall (or similiar).