Proxy SSH to hide endpoints [duplicate]
I'm still dubious of this (see my earlier answer). You can't do reverse proxies here, unless you have a reverse proxy that understands how to do ssh authentication, and even then, your proxy is an endpoint for the ssh connection, so it's privy to data going over it, and it has the ssh keys for the user connections, and connections to the servers behind it. If anyone gets access to that system, it's most likely game over for everything behind it.
You could avoid some of this risk if you're prepared to have users log in twice, with the second connection being tunnelled over the first connection to the bastion host, but you've said that's not what you're after.
So, you really do need to lock down your bastion host.
Your bastion host will need to have a bunch of user accounts, each with ssh private keys in their .ssh folders for logging into the hosts behind them. They'll also hold the public keys users log in with.
You'll need to make very sure that the users can't run anything on the bastion except ssh to the host on the network behind. Set that ssh command up in the ssh authorized_keys file, so logging in with the public key automatically runs the ssh command to connect to the host behind the bastion. See the AUTHORIZED KEYS section in man sshd, particularly the 'command=' bit.
- Keep to an abolute minimum the number of users who can do anything on the bastion other than the onwards ssh command. Maybe just root access. Maybe an admin user or two.
- Make sure the user cannot add arguments to the ssh command.
- No password access. SSH keys only.
- Disable AllowTcpForwarding, PermitTunnel, X11Forwarding
- Be very careful if you're setting up SSH Agent forwarding. Disable if not needed.
- Consider setting up per-user chroot directories with next to nothing in them.
I'm having trouble thinking of a good reason to want to do what you are describing. ie The possibilities I've thought of are mostly inadvisable.
I suggest you give more background on what the underlying problem you're trying to solve is, and that the answer might take you in quite a different direction anyway.
based on further info:
-
My first suggestion would be that you set up multiple forwarding ports on the bastion host, each forwarding to ssh on a different machine. If your users store the port in their .ssh/config files or putty configuration, then it's not a significant inconvenience.
-
You could have ssh accounts on the bastion host with commands specified in the authorized_keys file to connect to the appropriate hosts via ssh. You'd wind up with two ssh login processes, which is a little bit slow, but if you use an ssh agent and agent forwarding, it's not too painful. Agent forwarding does mean that if the bastion host was compromised, the ssh keys of anyone logged in at the time could be abused, for as long as they remain connected.
Option 2 is closer to what you asked for, but option 1 is better IMHO.
NB (Added much later)
Note that option 2 would have been affected by the Shell Shock bash exploit. I'd hope that people would have patched that long ago, but it's an example of how terminating ssh access at a host which then passes the connection through a second ssh connection is potentially vulnerable in ways that a port forwarding based solution is not.