SSH tunnel to secure RPC traffic on HTTPS url

[Jonathan Larsen]

Hello. I've been struggling to implement a secure solution for communication on RPC.
The server application that I am running is using RPC specifically on 127.0.0.1 on port 10854.
For those that might need to access my RPC server, the URL I want to give them is: https://cortex-coeus.asuscomm.com:8545.
FWIW, http://{LOCALIP, SERVERNAME}:8545 currently works using either of the following ssh commands:

sudo ssh -D 10.1.1.120:443 -L 10.1.1.120:8545:127.0.0.1:10854 -L 10.1.1.120:8546:127.0.0.1:10900 eff...@10.1.1.120 -p 44322

I've also tried:
sudo ssh -L *:443:10.1.1.120:8545 -L 10.1.1.120:8545:127.0.0.1:10854 -L 10.1.1.120:8546:127.0.0.1:10900 eff...@10.1.1.120 -p 44322

My router is forwarding 8545 and 443 to my internal server.

The server application is started so that the RPC port and address are: 127.0.0.1:10854.

I am mostly confused because the URL I want to give out has "two" associated ports with it. the HTTPS part of the URL and 8545.
I wasn't sure if potentially setting up a socks proxy would resolve the issues because I believe this to be a headers problem in the forwarding.

Below are results when connecting using the second ssh command from above. When using -D for a socks connection, I get a connection refused in the curl response.

root@cortex-coeus:/home/effofx# curl -H "Host: cortex-coeus.asuscomm.com" -L 10.1.1.120:443
curl: (52) Empty reply from server

root@cortex-coeus:/home/effofx# lsof -i -n -P | grep :443
sshd 727 root 3u IPv4 20175 0t0 TCP 10.1.1.120:44322 (LISTEN)
sshd 887 root 4u IPv4 27671 0t0 TCP 10.1.1.120:44322->10.1.1.101:56713 (ESTABLISHED)
sshd 999 effofx 4u IPv4 27671 0t0 TCP 10.1.1.120:44322->10.1.1.101:56713 (ESTABLISHED)
sshd 1009 root 4u IPv4 27919 0t0 TCP 10.1.1.120:44322->10.1.1.101:56721 (ESTABLISHED)
sshd 1078 effofx 4u IPv4 27919 0t0 TCP 10.1.1.120:44322->10.1.1.101:56721 (ESTABLISHED)
ssh 1927 root 3u IPv4 86835 0t0 TCP 10.1.1.120:52538->10.1.1.120:44322 (ESTABLISHED)
ssh 1927 root 4u IPv4 86839 0t0 TCP *:443 (LISTEN)
ssh 1927 root 5u IPv6 86840 0t0 TCP *:443 (LISTEN)
sshd 1928 root 4u IPv4 88739 0t0 TCP 10.1.1.120:44322->10.1.1.120:52538 (ESTABLISHED)
sshd 2007 effofx 4u IPv4 88739 0t0 TCP 10.1.1.120:44322->10.1.1.120:52538 (ESTABLISHED)

When starting the server, I see this in the auth.log
May 11 02:24:56 cortex-coeus sshd[2050]: pam_unix(sshd:session): session opened for user effofx by (uid=0)
May 11 02:24:56 cortex-coeus systemd-logind[699]: New session 12 of user effofx.
May 11 02:24:57 cortex-coeus sshd[2129]: error: connect_to 127.0.0.1 port 10854: failed.

And the prompt continues to display:
channel 3: open failed: connect failed: Connection refused

I am really confused, if I am being 100% honest, mostly because of this dual-port thing. Maybe I've overcomplicated it in my head? I am unsure of how to properly forward the https traffic externally on port 8545 to my internal server.
The reasoning behind needing a URL that is 'HTTPS' versus 'HTTP', is that when connecting to my nodes RPC server, metamask requires that the URL be HTTPS when not an internal address. I also want to ensure I am securing the traffic so that nothing can be injected to steal anything from any transfer. In the past, this has happened on the etherium chain. I attempted a nginx reverse proxy but, that wasn't working for me, and decided to see if there was another way.

I am trying to help a few people recover some of their cryptocurrency when transferred to an ERC20 addr instead of being on-chain.

[Jonathan Larsen]

> Below are results when connecting using the second ssh command from above. When using -D for a socks connection, I get a connection refused in the curl response.
>
> root@cortex-coeus:/home/effofx# curl -H "Host: cortex-coeus.asuscomm.com" -L 10.1.1.120:443
> curl: (52) Empty reply from server

Addendum to the above.

This error comes from the ssh -D *:443 part of the command I am running.
When the second one is used, curl does not return anything. This is also the case for if i instead change the curl command to 10.1.1.120:8545. So I had assumed it was working but trying to connect via https never happens.

Also, the error logs for failing to connect on port 10854 via 127.0.0.1 are probably because peers are trying to connect prior to my node restarting. Because once the node starts, they are not continually displayed on the console, which makes sense since it's the application opening those ports.

[Grant Taylor]

On 5/10/21 8:29 PM, Jonathan Larsen wrote:
> Hello. I've been struggling to implement a secure solution for
> communication on RPC. The server application that I am running is
> using RPC specifically on 127.0.0.1 on port 10854. For those that
> might need to access my RPC server, the URL I want to give them is:
> https://cortex-coeus.asuscomm.com:8545. FWIW, http://{LOCALIP,
> SERVERNAME}:8545 currently works using either of the following ssh
> commands:
>
> sudo ssh -D 10.1.1.120:443 -L 10.1.1.120:8545:127.0.0.1:10854 -L
> 10.1.1.120:8546:127.0.0.1:10900 eff...@10.1.1.120 -p 44322
>
> I've also tried: sudo ssh -L *:443:10.1.1.120:8545 -L
> 10.1.1.120:8545:127.0.0.1:10854 -L 10.1.1.120:8546:127.0.0.1:10900
> eff...@10.1.1.120 -p 44322

Are you sshing from yourself to yourself explicitly for the purpose of
the port forwarding from 10.1.1.120:<port> to 127.0.0.1:<port>?

> My router is forwarding 8545 and 443 to my internal server.

Okay.

> The server application is started so that the RPC port and address
> are: 127.0.0.1:10854.
>
> I am mostly confused because the URL I want to give out has "two"
> associated ports with it. the HTTPS part of the URL and 8545.

The HTTPS as in https:// is not a port in and of itself. Instead it's a
communications method / scheme to use across whatever port is specified.
If you don't explicitly specify a port, browsers default to port 443.

So http://{LOCALIP, SERVERNAME}:8545 really only specifies one port;
namely 8545.

> I wasn't sure if potentially setting up a socks proxy would resolve
> the issues because I believe this to be a headers problem in the
> forwarding.

No. I would expect that having the SSH client behave like a SOCKS proxy
would not help.

> Below are results when connecting using the second ssh command from
> above. When using -D for a socks connection, I get a connection
> refused in the curl response.
>
> root@cortex-coeus:/home/effofx# curl -H "Host:
> cortex-coeus.asuscomm.com" -L 10.1.1.120:443 curl: (52) Empty reply
> from server

It looks like you are trying to have curl connect to 10.1.1.120:443 as
an HTTP server, when your first command has that as the Dynamic (SOCKS)
proxy. Those are two different protocols that are incompatible with
each other.

> root@cortex-coeus:/home/effofx# lsof -i -n -P | grep :443
> sshd 727 root 3u IPv4 20175 0t0 TCP
> 10.1.1.120:44322 (LISTEN)
> sshd 887 root 4u IPv4 27671 0t0 TCP
> 10.1.1.120:44322->10.1.1.101:56713 (ESTABLISHED)
> sshd 999 effofx 4u IPv4 27671 0t0 TCP
> 10.1.1.120:44322->10.1.1.101:56713 (ESTABLISHED)
> sshd 1009 root 4u IPv4 27919 0t0 TCP
> 10.1.1.120:44322->10.1.1.101:56721 (ESTABLISHED)
> sshd 1078 effofx 4u IPv4 27919 0t0 TCP
> 10.1.1.120:44322->10.1.1.101:56721 (ESTABLISHED)
> ssh 1927 root 3u IPv4 86835 0t0 TCP
> 10.1.1.120:52538->10.1.1.120:44322 (ESTABLISHED)
> ssh 1927 root 4u IPv4 86839 0t0 TCP *:443
> (LISTEN)
> ssh 1927 root 5u IPv6 86840 0t0 TCP *:443
> (LISTEN)
> sshd 1928 root 4u IPv4 88739 0t0 TCP
> 10.1.1.120:44322->10.1.1.120:52538 (ESTABLISHED)
> sshd 2007 effofx 4u IPv4 88739 0t0 TCP
> 10.1.1.120:44322->10.1.1.120:52538 (ESTABLISHED)

What are all the 44322 ports? They seem unrelated.

> When starting the server, I see this in the auth.log
> May 11 02:24:56 cortex-coeus sshd[2050]: pam_unix(sshd:session):
> session opened for user effofx by (uid=0)
> May 11 02:24:56 cortex-coeus systemd-logind[699]: New session 12 of
> user effofx.
> May 11 02:24:57 cortex-coeus sshd[2129]: error: connect_to 127.0.0.1
> port 10854: failed.

I don't see enough information to know what is causing the error.

> And the prompt continues to display:
> channel 3: open failed: connect failed: Connection refused

I don't know if "channel 3" is significant or not. The number may just
be the arbitrary communications channel within the SSH connection.

"Connection refused" means that something isn't allowing the connection.

> I am really confused, if I am being 100% honest, mostly because of
> this dual-port thing. Maybe I've overcomplicated it in my head?
> I am unsure of how to properly forward the https traffic externally
> on port 8545 to my internal server.

If you're doing what I think you are doing, I wouldn't use SSH as part
of this tool chain. I'd use a firewall port redirection / NAT
capability -or- a TCP proxy / redirection application.

Yes, OpenSSH can probably be pressed into service to do this. But I
think it's quite a bit more complicated and definitely more overhead
than is needed to achieve the the result.

> The reasoning behind needing a URL that is 'HTTPS' versus 'HTTP',
> is that when connecting to my nodes RPC server, metamask requires
> that the URL be HTTPS when not an internal address.

1st: OpenSSH isn't going to do any HTTPS <-> HTTP protocol translation
for you.

2nd: What does "internal address" mean in this context? Any RFC 1918
private IP or 127.0.0.1/8 on the loopback interface?



--
Grant. . . .
unix || die