On Thu, Sep 27, 2012 at 8:44 PM, Kevin Winchester <
[email protected]> wrote:
Hi,
I see that TCP/IP forwarding has been added to the SSHD client in the
upcoming 0.8.0 release. I have grabbed the latest code from SVN to try it
out, but I have a few questions:
1. Is there any sample code for how to use it? I basically am doing the
following:
SshClient sshClient = SshClient.setUpDefaultClient()**;
sshClient.start();
ClientSession clientSession = sshClient.connect( host, port
).await().getSession();
clientSession.authPassword( username, password ).await();
clientSession.**startLocalPortForwarding( new SshdSocketAddress(
localAddress, localPort ), new SshdSocketAddress( remoteAddress, remotePort
) );
I don't want any shell or execution channel, just the port forwarding. Is
that the best way to make use of the feature?
Yes
Great, thanks. I plan to make more use of the asynchronous nature of
the API in the future. Would I be able to call connect(),
authPassword() and startLocalPortForwarding() without calling await() on
any of the Futures first?
Hmm. Looking at the code, it looks like I cannot get a valid
ClientSession from the ConnectFuture until the connection is complete,
so I guess I would not be able to call authPassword() without first
waiting. I don't see the same dependencies between authPassword() and
startLocalPortForwarding() though. Should I be able to call those in
sequence, or should I call await() on the AuthFuture first?
2. When I run the above code, the channel seems to work correctly, until I
disconnect for the first time, at which point the channel seems to close
itself. Is that something I am doing wrong, or is it the intended
behavior? Any other SSH client I have used maintains the forwarded channel
across multiple disconnects/reconnects.
I've just added a loop to the unit test we have and the current code seems
to support multiple socket opening/close correctly.
See testLocalForwardingNative in
https://github.com/apache/mina-sshd/blob/trunk/sshd-core/src/test/java/org/apache/sshd/PortForwardingTest.java#L189
Channels are created for each incoming socket connection on the remote side.
Are you saying that the channel is kept opened for a certain amount of time
before being closed if not reused ?
I suppose I can see the use case for example when using HTTP 1.0, but I
must admit that did not crossed my mind.
Feel free to raise a JIRA issue and eventually propose a patch if you're
fancy working on it.
I just tried again this morning and I saw exactly what you describe -
new channels were created for each connection to the forwarded port. I'm
not sure what was going on yesterday, but I'll continue my testing. If
I see the disconnection again, I'll grab the logs from server and client
(both are SSHD) and post them here.
3. I see that there is a createDirectTcpipChannel method in the
ClientSession class as well, that seems to create a completely different
implementation of a forwarded TCP/IP channel. What is that used for?
The main difference is that the startLocalPortForwarding opens a server
socket and will channel incoming connection through the ssh layer.
The createDirectTcpipChannel serves a slightly different purpose which is
to stream data from java to the remote host, so no socket is opened and you
have to give the input / output / error streams instead.
The reason the implementation is different is mainly because in
the startLocalPortForwarding case, no java streams are used, and we use bio
buffers, so even if ssh layer is used in the same way, the client side is
slightly different.
Good to know - thanks. The reason I asked is that the
startLocalPortForwarding method does not return any reference to the
channel. The reason I wanted to get the channel is that I was wondering
if there is a way to add a listener for channel events. Or
alternatively, I would love to be able to monitor the socket that gets
opened for port forwarding to know when it is ready/in use/closed. Is
there any support for those kinds of things? If not, would you be
willing to accept them if I managed to get them added to the code?
Thanks again for the quick responses. The more I look into the
well-organized code from this project, and the more I see your
willingness to help out users, the happier I am getting about choosing
SSHD for my project.
Kevin
