Otherwise, is makes running the script successfully more complicated when the Pi is prompted for the server user’s password. I did this with a simple shell script which is then run every minute by a Cron job.įirst order of business, was to generate SSH keys for the Pi and the server. In order for this to make any sense, I had to make sure the Pi is automatically creating the reverse SSH tunnel at all times. So, when the tunnel is up, connecting into port 2222 of the server is redirected to the Raspberry Pi. When a connection is received, it is forwarded to the previous connection that was established already from the Pi’s side.
Reverse ssh tunnel manager password#
I was prompted for the Pi user’s password and after a successful authentication, I was logged in to the pi.Įssentially what’s happening here, is that the public server is listening on port 2222 for incoming SSH connections.
After that nothing happened visually, the terminal was just waiting for something to happen.īack on the server, I typed in the following command: ssh -l pi -p 2222 localhost After answering “yes”, I typed in the user markus’ password. I was prompted that the authenticity of the host can’t be established and was asked whether I wanted to continue connecting, which was completely normal. There, I first made a hole in the wirewall to allow incoming connections to port 2222: sudo ufw allow 2222/tcpĪfter that, I went back on the Raspberry Pi and tried the ssh command above with promising results. This is when I logged in to our public server, which we’re currently trying to connect to from the Pi.
This was because the server was not currently allowing connection to port 2222. ssh -N -R 2222:localhost:22 connection was refused. To begin with, I tested how the reverse tunnel worked manually. So the idea is to start the tunnel connection from the Raspberry Pi. Whether we are going to use this approach in late production, depends on the reliability of the connection. After all, our Raspberry will be running of a battery in a mobile network. However, we have to figure out how taxing it is in terms of resources. In the end, we decided that SSH is the most versatile way to go about this.
We also thought about using remote configuration tools like Puppet or Salt. We discussed different ways we could approach this: a reverse SSH tunnel connected from the Raspberry Pi to the server would eliminate the problem with NAT, as our server is accessible by a public IP-address ,whereas the connection would not work the other way around. The problem is that the device is in a mobile network behind NAT, which means that accessing it regularly via normal SSH is not possible since it does not have a static public IP-address that we could connect in to. One of the main requirements for this project is to have a reliable method for managing our prototype remotely.
0 kommentar(er)
