When you do
ssh email@example.com -L 1234:localhost:5678
on host b.company.com, the following happens:
- On host B, ssh starts to listen on port 1234.
- On host A, a connection is made to
localhost (that is, host A again) on port 5678.
- Traffic on those two endpoints is forwarded over the ssh connection between A and B.
So the end result is that you can access port 5678 on host A by using port 1234 on host B.
The reason you have to type
localhost is because host A can also be a "jump server", i.e. an entrance point into some protected network. So if you can't access host C directly from host B, but you can access host A from host B, and host C from host A, you can do
ssh firstname.lastname@example.org -L 1234:c.company.com:5678
which will establish connections between host B and A, and between host A and C, and tunnel port 5678 on host C to port 1234 on host A.
This has two consequences:
If you are already using port 1234 on your client (host B) for other services, you can't use it for tunneling. You need to use a different port (but there's plenty to choose from).
In your browser, you'll always connect to the local endpoint of the tunnel, i.e.
localhost. Assigning names to remote hosts won't change this.
So no, what you want doesn't work this way.
In case it wasn't clear enough: You can very easily use different port numbers to you are already running local services. So assume you have hosts A, B and C which you want to reach this way, they all have services on port 80, and you are running your own web server on port 80. Then you do
ssh user@hosta -L 5000:localhost:80
ssh user@hostb -L 5001:localhost:80
ssh user@hostc -L 5002:localhost:80
and you can access them now in your browser by typing
http://localhost:80 will still access your own local server.
There's no real need for complicated constructions which involve assigning yourself lots of IP addresses, or remotealiases.