2

The below is not asking about name based virtual routing, but virtual routing using username or identity key.

Has anyone done SSH proxying that is transparent to the user, but the end host they are routed to is determined by any of the following: username, identity key, DNS hostname. I guess DNS hostname isn't possible with the protocol, but it could use the identity key.

For example, I want users to be able to all SSH to the same machine, but they end up on different VPS nodes: ssh -i identity_rsa user@example.com.

There are a few very nice features of doing this:

  1. The RSA host key is the same no matter what VPS you SSH into.
  2. The hostname could be the same, or (dubious) it could route on subdomain names. I'm not sure if this is in the protocol or it only uses the IP address to connect to a TCP socket.
  3. Zero configuration on the client side (proxy commands, multiple ssh tunnels, etc)
  4. All traffic is funneled through a gateway.

I'm worried this requires a custom (legitimate) MitM SSH server, because I want a normal end-to-end SSH connection that can do SCP and agent-forwarding.

Can agent forwarding work with forced commands? Could I create forced commands based on the public key, call SSH -A to the inside host?

rox0r
  • 147
  • 8

2 Answers2

1

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:

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

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

Community
  • 1
mc0e
  • 5,866
  • 18
  • 31
  • If i have 10 machines behind a bastion host and i want 10 users to each go to a different machine, but i don't want to have to do any configuration at all, I have to be able to multiplex access. Nginx does this with http/https using reverse http proxies. It doesn't look like there are reverse ssh proxies. – rox0r Jun 18 '13 at 22:01
  • What if i have a thousand users? I really want a configurable reverse-proxy that looks to a user like they are just connecting to the end host. – rox0r Jun 26 '13 at 19:08
  • 1000 ports is no problem. Having a single point of failure for access to 1000 users' systems is. Why don't you just get extra IP addresses if you're worried about using ports. Is IPv6 an option? – mc0e Jun 27 '13 at 15:56
  • It doesn't have to be a single point of failure -- there could be multiple reverse-proxies that are setup in a HA configuration. – rox0r Jun 28 '13 at 03:45
1

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.
mc0e
  • 5,866
  • 18
  • 31
  • Thanks for your brainstorming. The current solution is TCP port forwarding using arbitrary high-level ports. I want the same solution, but with the ease of use of using port 22 for all users. No need for customers to remember what port to use. I hacked an experimental version using AuthorizedKeysCommand to lookup a user's pubkey (and endpoint) and then run a Forced command to ssh to that machine. Unfortunately, this requires Agent Forwarding and only allows terminal use of SSH and not the other interesting uses. – rox0r Sep 02 '13 at 16:46
  • 1
    You don't need agent forwarding if you generate keys in user accounts on the gateway machine which are authorised on the target machines. And of course those keys need to be stored without encryption so the user doesn't need a password to use them. – mc0e Sep 11 '13 at 09:39