0

I'm looking to place a couple Raspberry Pis into some home networks while being able to access them via SSH from a remote client without any port forwarding.

The clients are not fixed, so any client should be able to connect to any of the Raspberry Pis.

My current idea is, to have each RPI open a reverse SSH connection to a central server which has a known IP, allowing the clients to connect to the C&C server which will then somehow forward the connection to one of the RPIs (Probably selected by which port the clients connects to the C&C server with)

So far, I know I have to make port 22 of my RPIs available to the C&C server like so:

Run on RPI: ssh -R 127.0.0.1:2222:127.0.0.1:22 user@[c&c ip]

Now the C&C can theoretically connect to it's local 2222 port to reach one of the Raspis, but so far I'm missing the ability to connect from he outside, through the C&C,to one of the RPIs.

EDIT: Solution found: On the C&C server, edit /etc/ssh/sshd_config and set gatewayports to yes.

You can now connect to the C&C server's port 2222 to reach the RPI.

Sketch

10
  • But what you're doing is a port forwarding (through an SSH tunnel) Nov 7, 2023 at 16:33
  • Why not to force IP to every RPi? (often you can do it on routers, or just you setup a fix IP address, router should not complain). It is much easier then your hack. Nov 7, 2023 at 16:34
  • @MarcusMüller Okay, technically correct. Just don't want to mess with individual router's port forwarding settings.
    – stackola
    Nov 7, 2023 at 16:35
  • @GiacomoCatenazzi how would that work? THese RPIs are, according to text and figures, on home networks, i.e., most probably behind NAT and/or dynamic IP addresses. Nov 7, 2023 at 16:35
  • @MarcusMüller: My interpretation of the question (so Stackola: please correct me): port forwarding is not useable because internal IP were not constant. But if we force the internal IP to be fix, then we can use port forwarding. Else the problem is the classical one (but I would solve with one RPi as jumphost for all other) Nov 7, 2023 at 16:40

1 Answer 1

0

without any port forwarding.

But what you're doing is a port forwarding (through an SSH tunnel)!

So, if you want to achieve that, it would seem intuitive that instead of assigning each RPi its own port on the server, which gets confusing pretty quickly, to have an internal network where each client and each RPi has a static IP address, and tunnel this private network through the public IP network. A VPN!

Then there's no real difference between your clients and the raspberry Pis: all are just machines in the VPN without static public addresses.

Pretty easy to set up these days: Just install the wireguard tools on all the involved machines, on each of them create public/private keypair (wg genkey | tee private_key | wg public_key).
Give each of the clients&RPis a config file that reads something like

[Interface]
PrivateKey = {Private key as generated on this machine}

# Pick an different individual address for each machine from the
# networks described below as allowed:
Address = 10.0.123.101, fd42:42:42:0:0101::
#                  ^^^               ^^^^^^
# Parts of the addresses to modify; I just randomly chose to 
# give 10.0.123.101 – 10.0.123.199 to your RPis, and 
# give 10.0.123.201 – 10.0.123.254 to your clients

DNS = {IP address of the DNS resolver to use}


[Peer]
PublicKey = {The public key from the server}
Endpoint = {The public IP address of the server}:{Port on the server}

# Allow addresses from the private networks:
#  IPv4: 10.0.123.0
#through 10.0.123.255
#
#  IPv6: fd00:1111:2222:1:0000:0000:0000:0000 
#through fd00:1111:2222:1:ffff:ffff:ffff:ffff
AllowedIPs = 10.0.123.0/24,fd00:1111:2222:1::1/64

and, nearly the same on the server, but listing all client machines as Peers:

[Interface]
PrivateKey = {Private key as generated on this machine (the server)}
Address = 10.0.123.0, fd42:42:42:0::
DNS = {IP address of the DNS resolver to use}

[Peer]
PublicKey = {The public key from the 1. RPi}
AllowedIPs = 10.0.123.101/32, fd42:42:42:0:0101::/128


[Peer]
PublicKey = {The public key from the 2. RPi}
AllowedIPs = 10.0.123.102/32, fd42:42:42:0:0102::/128
# all the other RPis…

# … and all of the "clients":
[Peer]
PublicKey = {The public key from the 1. client}
AllowedIPs = 10.0.123.201/32, fd42:42:42:0:0201::/128
[Peer]
PublicKey = {The public key from the 2. client}
AllowedIPs = 10.0.123.202/32, fd42:42:42:0:0202::/128
# …

That's really it (save these config files in /etc/wireguard/, e.g., as wgvpn0.conf; enable them using systemctl enable --now wg-quick@wgvpn0); you can now connect to to the first RPi (110.0.123.101 or fd42:42:42:0:0101::, depending on whether you want to use IPv4 or v6) from the clients using ssh 110.0.123.101.

7
  • Appreciate the response! I'm sure that would work, but for technical reasons I would really like to avoid using a VPN. Without getting into details, some of the client software I'm running does not support VPN. Eventually, this is all meant for an IP sharing solution, and while VPN seems like the perfect tool for that, the software we are using only supports HTTP proxies, Socks 4, Socks 5 or POSSH (Proxy over SSH). For simplicity, I figured I would just use POSSH, which would also allow for some remote maintainance.
    – stackola
    Nov 7, 2023 at 16:59
  • 1
    Sorry, but that's nonsense: the client software can't know that this is a VPN. It just sees a network interface with an IP address of e.g. "10.0.123.201". And no matter what you decide to call it, what you're building is a VPN, whether you like it or not. Nov 7, 2023 at 17:04
  • I know this might not be standard, but it's just what it is. I realize any individual software would not be able to even recognize it's using a VPN, but in our specific case it's still technically difficult, as a single client might need to connect to two RPIs simultaniously. As I said, we are using a software for that purpose, which only supports the IP-sharing stacks I have mentioned. So I guess I'm building a VPN with port forwarding WITHOUT using VPN or port forwarding.
    – stackola
    Nov 7, 2023 at 17:06
  • In our specific case it's still technically difficult, as a single client might need to connect to two RPIs simultaniously. That's not true. You need to re-read my answer in more detail: you just do a connection to each of them. It just works. Nov 7, 2023 at 17:09
  • As I said, we are using a software for that purpose, which only supports the IP-sharing stacks I have mentioned. So I guess I'm building a VPN with port forwarding WITHOUT using VPN or port forwarding that is simply not true. What you're building is usually called an SSH VPN, and what you're doing is forward ports through SSH. Nov 7, 2023 at 17:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .