I'll first describe a [unfortunate, hacky but easy to set up] solution. Then I'll describe why I don't think that exactly what you have described would be easy.
The machine at bouncer.mydomain.ltd will have one user for every user/host tuple. In each of the users on the bouncer machine will have a .bashrc:
Furthermore, public keys from the bouncer machine for each user can be placed in the
authorized_keys directory for the respective host's intended user.
The failure of this is that information is redundant, and any change to the specific hosts will not propagate (unless you introduce some hacky scripting)
The previous solution is really an ssh connection opened up from the shell of an ssh connection. I think you really were imagining something more like a reverse proxy that routed based on whatever you put in the user area.
Unfortunately, it is hard to extract that user area information. (And there is no software that I know of that does this already) When you type
ssh does not immediately just extract
janet_host3 and send it over to the server. Rather..
- SSH client and server negotiate over keys and algorithms
- client/server establish a secure(encypted) communication channel
Only then can the authentication happen. Through an encrypted channel.
It's important to note that your server cannot know which machine to proxy the connection information to until after some of the communication has been completed.
For reference, the following is an example some of the first pieces of information that a server receives (I ran ssh to my localhost).
So to solve this:
- Your server would have to negotiate its way through the transport stage, set up the encrypted communication channel, and then snipe the user information.
- Then, it can parse the user information and establish a new connection with the intended destination.
- After this, it could funnel everything the client has sent, and everything the client says from then on to the intended server.
Depending on why you want to set this up, maybe I can propose some alternate solutions :
If you just want aliases so that users have to remember different information, use DNS and cnames so that
hostn.bouncer.mydomain.tld sends users to the machine that they intend.
If you wanted to be able to monitor traffic using the bouncer machine.. you'll need to do one of the things described above. To sniff encrypted traffic, you have to be a middleman such that you decrypt the information then encrypt it again before sending it off.