SSH bounce box with transparent forwarding to backend hosts

sshssh-tunnel

First, is such a thing possible? Consider the following setup:

One public facing "SSH Bounce Box"

bouncer.mydomain.tld

Four private *nix systems

host1.mynet.local
host2.mynet.local
host3.mynet.local
host4.mynet.local

All running Open-SSH on port 22. Each private system has its own unique root password and unique users.

I want to be able to log into host1.mynet.local as root with this single command:

ssh host1@bouncer.mydomain.tld

The above would sign me on to host1.mynet.local SSH as root using the SSH bounce box without having to manually setup tunnels.

Also, consider the following possibility:

ssh janet_host3@bouncer.mydomain.tld

This should connect to host3.mynet.local as the user janet. The last "_" separated the username from the host identifier.

The problem is that this should be completely transparent to the end user. Meaning the work is done server side and not client side. The end user does not need to edit configuration files, setup tunnels, or edit .ssh/config files to make it work on there end.

Best Answer

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:

ssh user@hostn.mynet.local
exit

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 janet_host3@bouncer.mydomain.tld

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

SSH-2.0-OpenSSH_6.0p1 Debian-3ubuntu1
......%{A.Q..3....*~\.....ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-ex

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.

Related Topic