1

I'd like to access my remote devices (mostly a Raspberry Pi or similar single-board computers) over the internet without any configuration on routers. It's hard/slow to get accesses to users' routers in most cases. I try avoiding proprietary services like teamviewer and husarnet.

I'm totally new to networking:

  • Where to begin?
  • What are the interesting projects I should look at?
  • What do you have in your mind?

I'm thinking of making my own VPN server.

Having my first device connected to VPN, can I ssh to a remote device which is also connected to the same VPN?

Nepumuk
  • 687
Garid Z.
  • 542
  • You can use ssh to create a tunnel from the device through the router to a public server you control. You can then use that tunnel to access the device. – Panki Aug 12 '21 at 08:45
  • This should get you started: https://unix.stackexchange.com/questions/46235/how-does-reverse-ssh-tunneling-work/46271#46271 – Panki Aug 12 '21 at 08:45

1 Answers1

3

I've answered your question below, but before I do...

I'll start by saying it sounds like you are implementing some kind of IOT device. In this context it's a little unidiomatic to want an SSH connection. This can work with tens or even hundreds of customers. But it will rapidly become unmanageable.

Usually you should:

  • Deploy your OS upgrades as complete images... so no remote calls to apt-get dist-upgrade which can brick the device and force you to send an engineer to fix them.
  • Deploy your application in a similar manner, sending it as one complete package which self-deploys.
  • Consider tools similar to Puppet which can carry out maintenance unassisted and give a way to send the same upgrades to may devices simultaneously.

Having worked in this space with ~3,000 devices you really don't want to get in the habit of logging in via SSH if you can possibly avoid it.

Always consider security. If this opens up a hole for a hacker to get onto user's home network then it can end your business.

If dialling in through SSH is your only option then you have a few options.

Reverse SSH tunnel

You can configure the device to ssh into a remote server with a port forwarding back to port 22 on the device. Typically you do this on-demand, so include some trigger in your own software which tells it to do this.

The device would need to be told a "remote" port to use, and you would then need to know what that port is. So if the remote port was 1234, the device would dial out to your server:

ssh -R 1234:localhost:22 remote-server.example.com

You can then, yourself SSH into the remote server and from the server SSH onto the IOT device using the remote port previously mentioned:

ssh -p 1234 localhost

This is a bit convoluted but it works. You are making an SSH connection which is wrapped in an ssh connection. But it works!

Permanently attached VPN

As you mention you can setup a VPN server. I would avoid this server having any access to your own network.

You can find examples on the web for OpenVPN which will most likely be the right VPN technology for this situation. There's a couple of "gotyas" to avoid:

  • Users do crack into own devices. You can't entirely stop that.
    • You don't want to give your users access to snoop round your corporate network. Don't give your VPN server access to anything on your corporate network, make it standalone.
    • Don't enable OpenVPN's --client-to-client communication. Would let clients talk to each other which you don't want. However you will then need to consider how to use this VPN? Initiating SSH connections from the server will be fine. Otherwise how will you connect your laptop to the server such that it isn't a VPN client.
  • Make sure you have read up on "auto reconnect". VPNs drop disconnect without warning and the client will need to reconnect automatically.

UPnP

Most / All home routers support Universal Plug and Play. This would let your IOT device open a port on the user's home router letting you dial in directly.

This does work, but remember that some users disable this feature as they feel it is a security risk. Eg: blog discussion on the topic here.

Stéphane Chazelas
  • 544,893
Philip Couling
  • 18,733
  • --client-to-client isn't about the server (or what's beyond it) talking to the clients. It's about the server allowing intra-client communication inside the VPN setup rather than via the server's normal kernel-based routing and iptables. C2C bypasses the kernel packet handling so that (for example) iptables rules aren't checked – Chris Davies Aug 12 '21 at 11:53
  • @roaima perhapse I was unclear. What I meant was that to use this VPN you've set up. You won't be able to log your laptop onto the VPN and start SSHing into clients. That's because your laptop would also be a client and thus be unable to talk to the IOT devices. To Use the this VPN you would need to initiate the SSH sessions from the server itself, or something on it's network.... but since I've otherwise said this shouldn't be on the corporate network that pretty much limits it to SSH sessions originating from the server itself. – Philip Couling Aug 12 '21 at 12:52
  • @roaima I should check what additional iptables rules are required, OpenVPN's own documentation suggests that if this is disabled client can't talk to each other. But, now I think about it, that documentation may be a little misleading. – Philip Couling Aug 12 '21 at 12:53
  • 1
    Reverse SSH happens to be the thing I was looking for. (I came across the term Reverse-SSH but I was couldn't understand at that time) Thank you – Garid Z. Aug 12 '21 at 13:02
  • If you're using the VPN infrastructure itself as a client, and --client-to-client is disabled then you can (potentially) get to the oher VPN clients provided the Server is set up to route such traffic without blocks via iptables. If you've enabled C2C then you can definitely get to other clients because the routing is managed inside OpenVPN before the rest of the system gets to see any of the packets. The C2C flag itself does not prevent you reaching other VPN clients but it can facilitate it. – Chris Davies Aug 12 '21 at 13:05
  • @roaima yeah I see that. The documentation is certainly misleading. "Uncomment out the client-to-client directive if you would like connecting clients to be able to reach each other over the VPN. By default, clients will only be able to reach the server." found here and several others. I agree with you, though. I think a suggestion should be added to this answer to turn off net.ipv4.ip_forward also. – Philip Couling Aug 12 '21 at 13:34