What you would want to do is ssh FROM your "linux server" TO something on the outside, such as "my_other_server" or something else both servers can get to.
You would use ssh remote port forwarding.
[user@linux_server]$ ssh -R8022:localhost:22 my_other_server.com
Explaination: Connect to my_other_server and open port 8022 there which will forward back to me on port 22.
From my_other_server.com you will be able to ssh to localhost on port 8022, and have your traffic forwarded to linux_server piggybacking on the linux_server -> my_other_server tunnel
[user@linux_server]$ ssh -p8022 localhost
Explaination: Connect to myself on port 8022 which is forwarded to linux_server
If you have problems with the initial linux_server -> my_other_server tunnel dropping out, you could make a script to keep it open, adjust the keepalive settings, or use autossh.
NAT does its job fine, but port forwarding has a different job. To understand this, it is important to remember the difference between incoming connections and outgoing connections.
Suppose that you and I are going to have a phone conversation. I might call you, or you might call me. In either case, we will be able to send messages (sentences) back and forth, but there is a difference in who starts the call. If I call you, it is an outgoing connection for me and an incoming connection for you. For this to be possible, I will need to know your phone number first. When you pick up the phone, you get my caller ID (which is my phone number). For the purpose of this explanation, let us pretend that you need to know my phone number in order to talk back to me.
Now imagine that our phonecalls are routed through two other phones (the routers), who are connected to many people:
You <----> Router 1 <----> Router 2 <----> Me
^ ^
| |
v v
Many Many
Others Others
To make matters complicated, I know only the phone number of Router 1 and not your personal number. Conversely, you know only the phone number of Router 2 and not my personal number. When I call you, we have two problems:
- Router 1 somehow needs to know that the call must go to you and not to one of the many others it connects to.
- Router 2 somehow needs to know that when you talk back, the sentence must be sent to me and not to somebody else.
Port forwarding solves problem 1. Calling about Super User is a service which is conducted through port 42 by convention. You tell Router 1 to forward all calls about Super User to you, so when I call Router 1 on port 42, I get to talk to you. If you had not explicitly told Router 1 to do this, we would not be able to call.
NAT solves problem 2. Router 2 pretends to be the caller, because neither you nor Router 1 will take up the phone if the caller ID is unknown (my phone number). It then remembers that I am the actual caller, so when Router 2 receives a response from Router 1, it knows to send it to me.
The situation on the internet is almost exactly the same. You just have to mentally replace the phones by computers, phone numbers and caller IDs by IP addresses, and unknown phone numbers by reserved IP addresses (such as the 192.168.*.* range).
Best Answer
The key is the UPNP https://en.wikipedia.org/wiki/Universal_Plug_and_Play
The router must be UPNP capable, and UPNP service must enabled. If disabled, process in the question won't work.
The configuration done via UPNP commands instead router's web interface. But in both case, router gets configured, just the method different.
In this case the OS configure your router.
OS sends UPNP messages to the router. These are network packets, if you interested in deeply, you can find official UPNP protocol descriptions.
You can imagine it as there's 2 port-forward database. One managed by router web interface (portforward, virtual servers, naming different), another managed by clients of the routers. But both stored on the router, and apply to the router rules.