![]() The SSH client on the Raspberry PI, requests a “RemoteForward” of a port, say 2500, to the Raspberry Pi’s port 22. Next, after the ssh connection is established at “3” in the diagram. Just like the connections you make to websites. ![]() Note that it is able to communicate through the firewall at 2 without doing anything weird because this is an outgoing connection. When the raspberry pi gets a network connection, it SSH’s into the “Cloud Computer” this is represented by the “1” in the diagram. To break down the whirlwind I explained above. So lets just do it, and you can think about how this magic works elsewhere. SSH has built-in functionality to simply use that port as though I were ssh’ing directly onto the host. Its there just to host the port from the PI for exactly this type of connection. I ssh into it by using something called a Remote Proxy. Now, I want to get to that little PI running in a foreign network. When the ssh session is established, the raspberry PI remote-forwards its own SSH port from ec2-jump at a pre-defined port… say 2800. Ec2-jump is a host for which the raspberry pi already has ssh keys on disk. Once it gets it, the raspberry PI will ssh into a known host on the internet – lets call this host ec2-jump. The way this works – you setup your PI to wait for a network connection. To get around this is a wonderful tool called SSH Tunneling. Normally this is impossible because incoming connections are blocked by firewalls, or its simply a pain to keep track of a dynamically changing IP. Another use-case – as a professional, deploying a bit of software, or hardware, and you’d like to get metrics from it, or check in on its performance, or even – you’d like to install something after the box is in place. ![]() Or you just want to share a TMUX between your kids and their friends. Say you are helping a remote friend play with a pi. Reboot the Pi to test and you should be good to go.Sometimes you need your little linux box to be available for login even while it lives on foreign networks. * * * * * pi /usr/bin/screen -S reverse-ssh-tunnel -d -m autossh -M 65500 -i /home/pi/.ssh/id_rsa -o "ServerAliveInterval 20" -o "ServerAliveCountMax 3" -R 2222:localhost:22 You can use the following crontab entry that checks if the tunnel is up every minute: ![]() While this works if the pi is has any problems the tunnel will be gone so we will use a cron job to make sure that it is always up. Once that is done you can ssh into your public ssh server and run the following command:Ĭongratulations you now have a host you can control from the internet on a private network ( That you totally have permission to be plugged into, right?). There are plenty of guides on setting this up so I won’t spend time doing that here. Once you have that complete and are on the pi you can run the the following command:Īutossh -M 65500 -o ServerAliveInterval=20 -R 2222:localhost:22 Īutossh will use ports 6551 to send echo data over and back between server and host and open an ssh session on the public server to local port 2222 that will tunnel back to the SSH port on the Pi. Public SSH server ( I like DigitalOcean for this.).To set this up you will need the following: Here is a terrible diagram I put together using draw.io to explain: At a high level if an attacker can plug in one of these on your network and get internet access they own your network. I have a couple of old Raspberry Pi’s 2 laying around and have been meaning to turn them into “Remote Access Terminals” to demonstrate what happens if you do not do effective egress filtering on your network.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |