If you're looking at going even deeper into SSH tunneling and port redirection, I recently made The Cyber Plumber's Handbook free: <a href="https://github.com/opsdisk/the_cyber_plumbers_handbook" rel="nofollow">https://github.com/opsdisk/the_cyber_plumbers_handbook</a><p>I made it free to the HN community a few years back [1]. There is a paid interactive lab portion (details in the repo) if you are looking for hands-on experience.<p>Book Overview<p>This book is packed with practical and real world examples of SSH tunneling and port redirection in multiple realistic scenarios. It walks you through the basics of SSH tunneling (both local and remote port forwards), SOCKS proxies, port redirection, and how to utilize them with other tools like proxychains, nmap, Metasploit, and web browsers.<p>Advanced topics included SSHing through 4 jump boxes, throwing exploits through SSH tunnels, scanning assets using proxychains and Metasploit's Meterpreter, browsing the Internet through a SOCKS proxy, utilizing proxychains and nmap to scan targets, and leveraging Metasploit's Meterpreter portfwd command.<p>[1] <a href="https://news.ycombinator.com/item?id=19946941" rel="nofollow">https://news.ycombinator.com/item?id=19946941</a>
You can also change/add them after the ssh session has started.<p>This uses the escape mechanism. For help on that, hit return, type "~?" and hit return again.<p>From there you will see that "~#" will list them. And "~C" takes you to a line-oriented command prompt where you can add them.<p>For example, type return "~C", then at the prompt type "-L1234:localhost:22". Then in another window, type "telnet localhost 1234". Then back in the ssh window, type return "~#" and you will see the tunnel being used.<p>Another trick: if you don't need a shell and only want to forward ports, run "ssh -N" instead of "ssh".
I have read far too many ssh tunneling articles and all of them either forget about the bind address or just pretend that the only host that can be tunneled is localhost.<p>The fact is that ssh tunnels are bound to an interface on one side and the other can be any (reachable) host:port. So if example.com:1234 isn’t reachable from your host network, you can do a local port forward to example.com:1234 from an intermediary host that can reach example.com:1234
never knew ssh did tun/tap. live and learn.<p>my personal preference has been to use ssh -D and tsocks for this. it doesn't require root on either side and tsocks is elegant for inbueing just the processes you want with the ability to use the tunnel.
I wanted to build a TeamViewer-type system using reverse tunnels so that I could access my possibly NAT'd or dynamic IP machines from each other in a simple way. The typical use would be SSH control, copying files each way, VNC. I came up with something where each machine connects to a an always-on server with a domain name, and offers a reverse tunnel I can use to SSH down, but it occurs to me that there might be a better way, or even a tool someone has already build. Does anyone know of something like this?<p>(pwnat is pretty cool, but I don't think it does quite what I'm looking for)
Excellent article!<p>What’s also very interesting is that the article links to page from TrendMicro about malicious Android apps using Java’s version of SSH to infiltrate internal corporate networks.<p>TrendMicro’s own Android app ALSO contained the same Java SSH sdk.
For most use cases, you should also add a local bind, "-Llocalhost:5900:localhost:5900" or else everyone at the coffee shop will be able to access your insecure Vnc server
At work, we have a handful of VPCs that we all work with. At the moment, we have a bastion host in every VPC. When something needs attention while on call, the engineer needs to first figure out which bastion host to ash into and then the actual work starts.<p>I was wondering if there is a better way to setup a central bastion host with RBAC such that the attack vector is also not centralised. Does anyone here have ideas?
So, I’m kind of dumb and this article helped me in a tangible way. When I work with jupyter notebooks on an ec2 (where I already have ssh access), I go into terraform or the console and add my personal ip to allowed ips in the security group, and then access the notebook via EC2_PUBLIC_IP:JUPYTER_PORT in my browser. This is annoying in particular, in addition to needing to add an IP, in that when I move from the office to home or vice versa there’s always a brain fart where I cannot access because I’m on a new ip.<p>After reading this article I started a port forwarding session and can access the remote notebook without issue. All it took was the ssh port forwarding. Amazing.
I setup an RPI in a field at my dad’s w/ 900MHz internet bridge and wanted 24/7 remote access but didn’t want to pay for and configure VPN. At first I opened a router port but the RPI showed access attempts every few minutes, which was troubling. Learned enough about ssh tunneling to setup a systemd service to auto-attach the RPI to an AWS instance. (Also have an RPI on the bench attached as well.)<p>I always laugh when I ssh into AWS, then into the RPI (over the internet and then a 900MHz bridge). Then sometimes I ssh or ftp into a data logger running in the field. Good times and has worked relatively flawlessly for a few months. (I don’t have any uptime metrics for the network connection but no noticeable problems.)<p>I’m planning a few more which would be much more remote. Any other suggestions for managing such a setup? Some sites may have cellular connections and so I’m not sure I want 24/7 ssh tunnel (though I don’t think it uses too much data).<p>Edit: I see others recommending WireGuard for similar situation. Never heard of it will check out.