SSH tunnelling is an utter necessity in the ridiculous corporate environment I work in. Incredible amounts of bureaucracy and sometimes weeks of waiting to get access to stuff, get ports opened, get some exception in their firewalls and vpn so someone can access a thing they need to do their job.
This guide mentions -D but doesn't really articulate quite how powerful it is if you don't know what it does.
ssh -D 8888 someserver, set your browser's SOCKS proxy to localhost:8888 (firefox still lets you set this without altering system defaults). Now all your browser's traffic is routed via someserver.
That was pretty much my standard way to browse the web away from home in the mid 2000s. But when I actually got a corporate job they had whitelisted IP addresses so I couldn't even get an SSH connection to some random box on the net. I was so miserable I started to look into setting up http tunnel and somehow getting a box I controlled whitelisted. But instead of going that far I just changed jobs.
It isn't a good idea to circumvent corporate environment networks. they're there for a reason, and doing it shows a lack of professionalism and dis-respect for the organization process, procedures, and security. Yes it takes weeks/months to get access, then it takes weeks/months to get access. You don't want to be held liable for opening a backdoor to confidential information, or compromising their security.
Exactly. It's not a good idea to bypass policies at work. Just because you don't know why the policy is there or you disagree with the reason, it doesn't mean you can ignore the policy.
If you can't get your job done, then escalate the issue to your manager. You not being able to get your work done because of other teams is the kind of problem they're supposed to be solving.
If you let me ssh on that server and I am allowed to ssh from there elsewhere that is not bypassing anything. You allowed me to do that unless it says somewhere that tunnels are not allowed. The question is mainly for which purposes you allowed me to use these things and whether I comply with that. E.g. if I was given a ssh route to reach the some internal LDAP system for software development reasons and I abuse it to stream cat videos on youtube that is on me. But if I use it to reach another internal server that I use for software development, then it is on them.
The alternative would be asking a babysitter for each connection you are making. Sounds like a good way to never get work done.
Also: A good sysadmin will have lines in their /etc/ssh/sshd_config that prevent me from tunneling if they don't want me to do it.
This is the approach I take too. If I need it and I can do it then I'm going to. If you don't want me to then block me.
I must say I've had some raised eyebrows over that approach but if the alternative is not getting my shit done then I'm gonna do it unless explicitly forbidden.
Bypassing corporate policy at work is risky. You might bring down negative consequences on yourself or your workplace. You have to understand what you are doing. You have to understand likely reactions.
But also, bypassing corporate policy can have benefits. If I'm more productive or get a reputation as the guy who gets things done or don't get seen as a complainer or just generally produce results because I bypassed a policy, those are all benefits. If I can transform "hey boss, it's gonna be another week on this project because I'm waiting on a policy exemption" to "here it is", that's a benefit.
You have to weigh whether the benefits outweigh the risks for you.
Depends on what you mean by bypassing. If it is a workaround that is not prohibited but rather just not known by ICT and most users, there's as good as no personal risk.
If on the other hand, it is sabotaging or disabling safety systems, e.g. exposing the internal network to outside the corporation or writing passwords on a paper lying on your desk, then you can get blamed.
My experience is that this will always be a kind of cat and mouse game and that is just fine. It keeps ICT sharp while there always are possible ways to cut some corners if things need to move forward. Alternatives would mostly be ultimate chaos or crippling bureaucracy.
I do agree, but I'm not sure people are actually thinking about the potential risks. Because it's easy to say "what risk can there possibly be?" but it's hard to actually answer that dismissive question.
Also, the if there is risk analysis it may be overly focused on the short term. I've worked with "here it is" kind of people... and had to deal with the messes they leave behind. Those people get praised in the moment at the expense of the future (some of those cases were actually recognized eventually and the people were let go).
Sometimes they are. Sometimes that reason is long forgotten, or isn't really valid anymore, or is an overprotective measure and not really a good reason in the first place. Quite often it doesn't justify waiting weeks or months to get it changed.
[...] they're there for a reason [...] Yes it takes weeks/months to get access, then it takes weeks/months to get access.
Not exactly. Everyone has to evaluate for themselves how legit the rules are and act accordingly. More often than not, boilerplate rules are thoughtlessly applied and there is no pragmatic process to handle the exceptions to those rules.
Admittedly, it's a risk to break such rules. One has to be an adult and use good judgement. It's OK, most of the time.
In many corporate cases, SSH tunneling is the desired way of accessing a closed by default port on a firewall. Very often from a predefined bastion host.
If you don't want to open a range of IPs, it allows only people with their ssh key registered on either a selected bastion host or the server to open a specific port.
It can also be a way to authenticate users. For example if you want to secure the access to an open source version of an app for which only the proprietary enterprise tier allow authentication by ldap/AD/oauth2. You can have ssh authenticate against LDAP/AD/oauth2 and leave the app running without authentication enabled or with a single user. As long as you don't need RBAC/privilege separation or some kind of auditing of what each user does on the app this is a particularly valid solution.
I will do everything by the book if your company gives me a person that can help me within half an hour. If every request needs days to complete and then doesn't work and then I have to make another request – if I wouldn't know better I would call it sabotage.
From the CIA simple sabotage field manual: Insist on doing everything through “channels.” Never permit short-cuts to be taken in order to expedite decisions.
"Waiting for corporate to punch a hole through three firewalls for me to get access to the test server :P"
I was on a project once where a consultant had dropped their laptop and it had taken a week or two to get fixed. After that everyone had to use a laptop provided by the client. When we scaled up the project with 3 more developers the project manager who had set up this policy discovered that the lead time for 3 dev laptops meant that the new developers got to be bored for a month at a fairly high hourly rate.
That is an awfully specific question. Here are a few examples of what could happen though:
- Malicious code on a webpage compromises your computer.
- You download unauthorized software to install, which possibly even comes from a known-bad source.
- Your employer could have trouble establishing that their patent is legitimate because you accessed documentation from a competitor.
Even if the worker avoids liability for costly mistakes, the company will be set back. You can also be fired for breaking rules like that even when there are no actual damages.
This guide mentions -D but doesn't really articulate quite how powerful it is if you don't know what it does.
ssh -D 8888 someserver, set your browser's SOCKS proxy to localhost:8888 (firefox still lets you set this without altering system defaults). Now all your browser's traffic is routed via someserver.
I find that to be incredibly useful.