Free book to master SSH tunneling concepts
github.comLooks interesting, will give it a read as it looks to cover more than the basics.
Years ago I worked in a SOC doing managed services for a major telco provider, and for some reason they thought that we didn't have the need to do any kind of SSH tunneling to manage routers/switches/firewalls. They kept blocking it at various layers, and we kept having to find more and more creative ways to get around it. I think at one point we were hosting our own PAC files local to our machines, building three layers of tunnels (the last of which being a dynamic SOCKS tunnel), and using a portable browser (because we couldn't be trusted with admin!) with FoxyProxy (or similar) to finally reach our destination.
It’s pretty much impossible to validate that you are meeting the terms of your contract re: security policy if you’re doing that. You almost certainly were if you were providing SOC services to a big telco.
I have terminated contracts for cause and in one case got a vendor suspended from a big centralized procurement contract for pulling bullshit like what you described.
Folks do all sorts of naughty things with SSH. Back when we used to work in an office, one guy would tunnel out and proxy all his web connections through an SSH socks proxy so the employer's IT would not monitor his web traffic. Another guy would do reverse tunnels from his work PC to home, so he could connect to work without using the VPN.
The telco was providing the managed services in this case. That is interesting, so it sounds like this was a complete breakdown in the process somewhere. We weren’t doing it for fun or sport, we were doing it because it was the only way to effectively do our job.
I've been there but nowadays my policy is to let my employer/customer get hit with downtime if they don't provide me with ways to effectively do my work.
Absolutely — that’s nuts! I was in the managed services biz for some time, I can’t imagine facing our auditors having allowed third party contractors to do stuff like that.
>You almost certainly were if
Don't you mean they almost certainly weren't? It's hard to understand the rest otherwise.
No, gp is speaking from the point of view of those who set up the security measure.
Once you start poking holes into the security it's hard to assure you only did it for a good cause or with good intentions (whatever that means).
I still don't get it:
The original:
"It’s pretty much impossible to validate that you are meeting the terms of your contract re: security policy if you’re doing that. You almost certainly were if you were providing SOC services to a big telco."
That second sentence seems to be only interpretable as:
You almost certainly were meeting the terms of your contract re: security policy if you were providing SOC services to a big telco.
However it also says it's impossible to validate - so if it is impossible to validate that you were meeting the terms of your contract re: security policy, it must mean you weren't meeting the terms of your contract because such a contract will require validation.
But I guess I should let it go.
Thank you for such a thorough book...
This book does discuss autossh [1] which I came to know about recently while setting up my dynamic home ip (w/ CG-NAT) as the exit node in a wireguard network to overcome geo-restrictions on streaming services when traveling... :p
autossh [1] is such a simple and useful utility, wish I had known about it earlier when any connection changes in VPN/WiFi used to break my ssh tunnels to the corporate network during development...
If you're a frequent user of ssh tunnels, do check out autossh... ;)
I used autossh many years ago. There was nothing wrong with it. But with systemd user service managers available everywhere I just put a normal ssh command into a service file with RestartAlways and activate linger for the user.
No need to install an extra package. No idea whether it is maintained or not, but I know systemd is, both upstream and in the distro.
> I used autossh many years ago. There was nothing wrong with it. But with systemd user service managers available everywhere I just put a normal ssh command into a service file with RestartAlways and activate linger for the user.
Thanks, there will be multiple ways to do same thing, user can choose whichever they find the easiest...
Adding an example of such systemd file - https://gist.github.com/drmalex07/c0f9304deea566842490
> No need to install an extra package. No idea whether it is maintained or not, but I know systemd is, both upstream and in the distro.
Definitely not updated with the same frequency as systemd... https://salsa.debian.org/debian/autossh
Similarly, with "sshuttle" you can pick n mix from different subnets with ease, or even forward your entire internet over SSH without a proxy for "poor mans VPN"
... although for the later purpose it's no where near as CPU efficient as wiregaurd, but with non root access to any SSH server it can get you around barriers in a pinch with only TCP 443 available, and effectively "VPN" multiple potentially conflicting subnets at the same time - I've not seen any other tool that can do the latter so effortlessly.
I used local forwarding for years before learning about remote forwarding, which is useful for creating your own self-hosted ngrok-like service. A good number of the solutions on this list are based on SSH remote forwarding:
May I take this occasion to ask for help with merging my autossh commands? https://serverfault.com/q/1088997/64874
Without even opening the link I was about to say that the only book on the topic you should read is the Cyber Plumber's Handbook. I'm smiling that it's the same link. Haha.
Can’t even open it on macOS, iPhone with either Firefox nor Safari.
Is this just the man page for ssh? I’m not sure what’s going on here. If you understand the tool you know the ways it can be used.