Instead, configure your ~/.ssh/config with LocalForward, RemoteForward, and ProxyJump. This can save you a significant amount of time, especially when using ssh, scp, or rsync to transfer data from a remote server that requires multiple intermediate SSH connections.

e.g:

    Host jump-host-1
        HostName jump1.example.com
        User your_username
        IdentityFile ~/.ssh/id_rsa

        Host jump-host-2
            HostName jump2.example.com
            User your_username
            IdentityFile ~/.ssh/id_rsa
            ProxyJump jump-host-1

            Host jump-host-3
                HostName jump3.example.com
                User your_username
                IdentityFile ~/.ssh/id_rsa
                ProxyJump jump-host-2

                Host target-server
                    HostName target.example.com
                    User your_username
                    IdentityFile ~/.ssh/id_rsa
                    ProxyJump jump-host-3
                    LocalForward 0.0.0.0:8080 0.0.0.0:80  
                    RemoteForward 0.0.0.0:9022 0.0.0.0:22

    # after this:
    # - you can ssh/scp/rsync to your target-server via an alias
    # - forward traffic FROM port 80 on your target-server to port 8080 on your local machine
    # - forward ssh requests TO port 9022 on your target-server to port 22 on your local machine
    # - remember, for LocalForward & RemoteForward : 
    #   + left is target-server
    #   + right is your local
    #   + use 0.0.0.0 instead of localhost or 127.0.0.1

My home network is set up so that if I'm home or on my self-hosted VPN, I can SSH directly to my various things. But if I'm away from home and not on the VPN, I can SSH into my home systems through a jump host.

In the ssh_config file, I have it configured to detect how/where I am and optionally use a jump host.

  Host jump jump.example.org
    HostName                        jump.example.org
    Port                            41444
    User                            mmh
    UserKnownHostsFile              /dev/null
    ChallengeResponseAuthentication no
    CheckHostIP                     no
    Compression                     yes
    ForwardX11                      no
    GSSAPIAuthentication            no
    LogLevel                        ERROR
    PreferredAuthentications        publickey,keyboard-interactive
    ProxyJump                       none
    PermitLocalCommand              yes

  # Order here matters. Detect VPN first, then home network.
  # If connecting to a *.example.org host and router.example.org = 10.0.0.1, must be home/vpn.
  Match host *.example.org exec "getent ahosts router.example.org | grep -q ^10.0.0.1"
    ProxyJump                 none
  # If connecting to a *.example.org host and the macaddr of 10.0.0.1 is NOT 2a:70:ff:ff:ff:ff, then use jump.example.org:
  Match host *.example.org exec "! arp -ne 10.0.0.1 | grep -Fq 2a:70:ff:ff:ff:ff"
    ProxyJump                 jump.example.org


  ## Define the things
  Host tv tv.example.org
    HostName                  tv.example.org
    User                      mmh

Sometimes you just want to do it once and you don't want to write a config file for it.

For example, I am often building up a short lived vps in order to use ssh as a socks proxy and bypass georestrictions.

Also it happens that sometimes you are asked to help a different team and need to access a server you aren't accessing usually and have very few reasons to ever access again.

OTOH if I'm going to use some tunnelling/port forwarding quite often, I would use the config file option, but for an one time or sporadic use, the command line option is better IMHO.

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.

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.

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.

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.

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.

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).

    [...] they're there for a reason [...] Yes it takes weeks/months to get access, then it takes weeks/months to get access.

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.

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.

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 meant that A could connect to B, and only B could connect to C. The data I had to move from facility A to facility C via B in the most ridiculous rsync+ssh tunnel+keys+routing shenanigan mashup I've ever done. It took a few tries to get the incantation exactly right, but it was magical seeing it all move as one.

Looking back it is super obvious how I'd do it now, but back then being green, was a huge accomplishment. I still remember the exhilaration when I confirmed everything was synced up.

What I'd really like is just some visual tool to configure my tunnels instead of spending 30 minutes very few months when I need to use a tunnel.

> It lowers the throughput due to more overhead and increases the latency. On connections with packet loss or high latencies (e.x. satellite) it can cause a TCP meltdown.

This actually isn't a problem with SSH tunnels unless you're using TAP/TUN, because It unpacks and forwards the TCP streams. But you can still get reduced performance with multiple channels due to head of line blocking.

Been using it ever since for so much more than just bypassing firewalls.

- Streaming region locked content from overseas.

- Permanent reverse-tunnel for remote-access with autossh.

- Increased security compared to making services visible to the internet.

- Downloading scientific articles using my university's connection as a proxy.

Anything on 10/8 automatic tunnel it's pretty much a vpn over ssh

- A wants to SSH into B

- B tells A that it must connect to C instead

- A transparently connects to C directly

- B is not a part of the critical data path anymore

Does something like this exist?

Otherwise you can use jump functionality

From A:

    ssh -J B C

Maybe you can explain the problem more and perhaps there's a more suitable solution?

If you have a host that's somewhat embedded, you can have DNS handle the "routing" for you. You will have to handle fingerprint verification.

Sure it's a crutch, ugly and probably unsafe but I'm not a networking guy and need to get my actual stuff done.