Answer by Kamil Maciorowski for SSH upgrade proxy connection to direct connection

A pretty standard method of solving this (at least in case of IPv4) is as follows:

1. You ssh into the remote host via a proxy.

2. Once there, you ssh back to your local computer without a proxy. This requires an SSH server in your local OS; plus port forwarding in case of NAT, so you can actually reach your local SSH server from the remote host. The connection in this step should create a tunnel through which you will reach the remote host in the next step. The command will be like:

   # on remotessh -N -R 2222:localhost:22 -p port user@address

   where address shall be replaced with the public IP address to access your local SSH server, port shall be replaced with the right TCP port for that; replace user with your local username. 2222 is pretty much arbitrary and localhost:22 assumes the SSH server on the remote host listens on the loopback interface on port 22 (it's the default port for SSH).

   ^{(This answer does not explain how to set up port forwarding in case of NAT on the local side. This is an orthogonal topic.)}

3. Now your local SSH server should listen on the loopback interface on TCP port 2222 and this is your new tunnel to TCP port 22 of the remote host, where its SSH server listens. The tunnel uses the previous connection, it does not use the proxy. Use the tunnel like this:

   # on localssh -p 2222 ruser@localhost

   where ruser is your username on the remote host.

Notes:

• I wrote that 2222 is pretty much arbitrary. It shall be in the range from 1024 (inclusive) to 65535 (inclusive). Ports below 1024 are reserved for root.
• In step 2 consider adding -f, so the connection eventually goes to the background; or run this ssh under screen or tmux. Then you will hopefully be able to close the connection that uses the proxy (from step 1). Note the remote OS may be configured to log you out upon inactivity and/or kill all your processes when you log out; and/or SSH server(s) may impose some timeouts. E.g. it may happen the first connection gets terminated because of inactivity, then the second connection gets terminated because the remote OS does not let it linger, then the third connection terminates because the tunnel is no more. If the connection from step 3 keeps breaking then you should investigate these.
• In general it is possible to set up the remote host, so it keeps trying ssh (or autossh) to perform step 2 for you. Then you won't need step 1 and step 2 will happen automatically; you just do step 3 (and if it fails then you know you should wait a moment until the remote host "phones home" again; or you take emergency step 1 to investigate).
• In step 3 you ssh via a tunnel created in step 2. You tunnel SSH through SSH. Whatever data travels through the final connection, it will be encrypted (and possibly compressed) twice. Performance-wise this is suboptimal. If it's an issue then in step 3 disable compression and use the simplest possible cipher. I have found this question: How can I disable encryption on openssh? It's old, the answers are old, I don't know how good they are in 2025.