Create SSH Client Custom Shell Command in Fileserver

0 votes
asked Jun 1 by adrianwatkins (180 points)

I have a requirement for a SSH Client (and also a telnet client) to be able to be run and started as a command wihtin a Fileserver SSH shell as a custom action.

I appreciate i will only be able to do username/password authentication and be unable to pass keys or fingerprint end to end. in effect it needs to work the same was a jumping off a normal unix shell.

Ive hooked up input console stream ok, but am struggling to work out the best way to control and output SSH client (or telnet) and have tried to use virtualterminal or scripting without luck. Ideally the full payload in each direction will be proxied as there is no need for terminal emulaito or other payload manipulation.

2 Answers

0 votes
answered Jun 1 by Lukas Pokorny (123,470 points)

This scenario falls somewhat outside of what Rebex File Server and it's build-in simple shell was designed to do. Basically, you would have to handle the whole SSH shell yourself. Our SSH client objects such as Scripting and VirtualTerminal most likely won't be suitable for this scenario either.

Please check out How to execute an external process using Rebex SSH Server - the same approach outlined in the reply would be suitable for your scenario as well. Just instead of executing hg, you would either execute a custom shell application that provides the functionality you need (such as ssh or telnet commands), or implement that functionality in the same .NET application.

But unfortunately, this means you would have to implement the whole custom shell logic, because our simple virtual shell is not powerful enough to handle this, and there are no near-term plans to extend it.

commented Jun 1 by adrianwatkins (180 points)
Thansk for the quick reply. I started tryign to use a modification of the example of executing an external process and Im using this to get the incoming and outgoing streams of the SSH shell. However I cant seem to run ssh for windows because:

1. I had to run as 64 bit app to be able to access 64 bit ssh.exe
2. ssh seems to run in its own shell so I cant access stdin/out

As it is at the moment I have it so anything I send from the SSH console is getting to the client side SSH and hitting the final destination by reading the  consoleInput and sending it via scripting to a client using SendData. However Im not able to collect the incoming data from the SSH client using anything ive tried so far. Im sort of looking for the SSH client incoming data in some means.
commented Jun 2 by Lukas Pokorny (123,470 points)
Well, after looking more into this, it looks like proxying to applications such as ssh.exe that are actually supposed to run with a virtual terminal might be somewhat more complicated due to that requirement. I believe that one could use Windows ConPTY API for that (available since Windows 10 -, but that would involve implementing lot of interop code for its native API... We have not looked into that yet, although we plan to soon. So if the approach with Process/ReceiveData works for you, it does actually sound like the most simple solution.
0 votes
answered Jun 2 by adrianwatkins (180 points)

I persevered on this a little further and was able to get this working by using the Scripting object both with SSH and Telnet clients to connect and them and manage the data exchange back and forth as far as a proof of concept.

I had to poll the scripting Process with a short timeout and then check for ReceivedData but it seems to work in testing ok.

commented Jun 2 by Lukas Pokorny (123,470 points)
Thans for the update! If this is sufficient for your scenario, that might indeed be a usable approach. I'm not quite sure whether this could be used to replicate a full-featured ssh.exe, but perhaps there is no need for that (that depends on the needs of the clients that are going to connect to this via Rebex File Server).
commented Jun 2 by Lukas Pokorny (123,470 points)
One more suggestion - if it turns out this approach is not sufficient, it might be possible to use the low-level client-side SshSession API instead, which makes it possible to work directly with SSH channels in a stream-like manner. There are not many samples for this low-level API, but if you decide to give this a try, we can provide some sample code.