Limiting access to networks through centrally controlled ssh jumpbox

Question

I need to restrict access to many networks which I have no control over and am planning on using a jumpbox to be the single point of entry into all of the environments. A user would log in with their ldap credentials as well as their ssh key and then jump from here to a set of hosts that they are allowed to access.

The core issue is the limiting where a user is allowed to access. Since this is a shared resource where many members of our teams have access to, how do I limit this access. I thought that there might be a way with radius, but I did not see any. I would like to make this as easy as possible, i.e.

ssh -t user@jumpbox ssh user@remote_host

Where remote_host would be a system they are allowed access to.

My ideas are as follows:

1. (most resource intensive) a jumpbox per user, and manage the routes centrally through puppet as to what they are allowed access to. This would likely be the easiest to manage as it would be a VM per user.

2. (most painful for the users) Set up a script which is the only thing the user can run which gives them a selection. This would be a pain as the user would have to select from a potentially long list. This could also be easy to get around.

What have other people done to solve this issue?

Answer 1

I do this with groups, and the iptables -m owner --gid-owner rule in the OUTPUT chain.

Traffic leaving the jumpbox is controlled according to various groups:

# timesheet people go to the timesheet rule
iptables -A OUTPUT -m owner --gid-owner 401 -j TIMESHEET
# debt mgmt people go to the debt rule
iptables -A OUTPUT -m owner --gid-owner 402 -j DEBT
# end to end testing people
iptables -A OUTPUT -m owner --gid-owner 403 -j E2E

Then each of those custom chains will implement a (sometimes fairly complex) set of rules about what system(s) people matching that chain can access. A simple one might be:

# people in the primary group timesheet can go to the timesheet app http://192.168.12.38:17001/
iptables -A TIMESHEET -p tcp --dport 17001 -d 192.168.12.38 -j ACCEPT
# but can't do anything else, with logging
iptables -A TIMESHEET -j LOG --log-prefix "TIMESHEET REJECT: "
iptables -A TIMESHEET -j REJECT

Once this is set up, allowing access is just a matter of putting someone in primary group 401 (for timesheet), 402 (for debt management) and so on. If I wanted to allow high complexity, I could use --uid-owner and have a different chain for each user, but instead I keep my life a bit simpler by having the groups.

Answer 2

If I had to use SSH as my access control layer, I'd mandate the use of keys to access the bastion host, then put a force_command on each key to call a script with an identifier for the user behind the key. The script would then validate the access control permissions for the user identified, and fire up a netcat session to the appropriate machine. The user would be using ProxyCommand locally to proxy through the bastion host to the actual destination machine, and hence the user could then SSH through the netcat tunnel to the machine of interest, preferably again via SSH keys.

Answer 3

You can configure sshd_config on the destination to allow specific users from specific hosts with the following directive.

AllowUsers username@foot

So in one server, you can restrict access to this user from the jump server. (Assuming that your jump server address is 192.168.15.15.

AllowUsers joeuser@192.168.15.15 

And restrict access to just another user from that jump server:

AllowUsers janeuser@192.168.15.15

You can also use pattern matching with this directive (per man sshd_config). Note that depending on the number of users you have on staff, you may need to do significant administration with the configuration file. This will also impact any scripts you use to login to the server, as logins will be limited to what is in the AllowUsers after you add that in.