2

So this is my setup:

  • We have a few machines in a LAN, used for computation, which me and my colleagues access from the outside with SSH.
  • All our accounts on the LAN machines are managed and shared via LDAP (resides in the LAN, but is only accessible with SSL).
  • Access from the outside is restricted through one of the machines (SSH on port other than 22 and runs Fail2Ban). Password authentication is disabled and all users use passphrase-encrypted keys when logging in from outside the LAN. Root login is also disabled throughout the network.

However, as it is common to switch from machine to machine, many users use paswordless login within the LAN. This means that if an attacker gains access to that outside-facing host, he has the same level of access throughout the LAN as the user which was compromised.

How can I mitigate this risk? What are some good practices to follow? Are there other glaring issues with my setup?

nikitautiu
  • 135
  • 5

2 Answers2

2

You can use SSH Jump host (ssh -J) to connect to the internal machine via the external facing machine. This setup means that the key materials resides in your workstation instead of on the gateway. When using jump host setup, your local workstation negotiate the SSH connection to the internal machines directly, so an attacker that pwned the jump host cannot intercept the connection to your internal machine.

If you want to initiate connection after you are connected to the gateway, you can instead use agent forwarding (ssh -A). Note that this is less secure than the jump host setup, as an attacker that pwned the gateway can in use the forwarded agent socket to create new connections to the internal machine. To protect against this, you can configure your local ssh agent to display confirmation dialog before the agent needs to sign a new connection. Note also though, under this setup, the gateway can intercept communications as the session will be decrypted by the gateway before forwarding to the internal machine. In general the jump host is preferred, but there are situations where agent forwarding makes sense, for example, if you need to transfer files directly between the jump host and the internal machine, instead of having to route through your local workstation.

Lie Ryan
  • 31,089
  • 6
  • 68
  • 93
  • Great explanation, didn't know about jump hosts, but sounds like the way to go. Also as an added detail, one of the machines is also a workstation, used by a colleague. Should I disallow it to connect with a key within the network in case his account is compromised? Is this a inherent flaw of having a workstation within the network? – nikitautiu Nov 26 '18 at 16:30
  • @nikitautiu Nothing inherently wrong about that, but you and your colleague who uses the machine just have to decide what the risks are and decide whether it's worth the benefit – Lie Ryan Nov 26 '18 at 21:41
0

Lie's answer already covers most of the aspects.

Here are some additional aspects regarding security of the client's key pair(s):

  • You have to establish an authorized key management which automatically removes public keys of inactive / deleted users
  • It's highly recommended to enforce a policy for client key rotation.
  • You cannot effectively enforce a strong private key protection unless you enroll crypto hardware tokens for the users, but those are slow.

Therefore I'd recommend to use temporary OpenSSH client certificates you issue after multi-factor authc and which are valid only for a couple of hours.

Michael Ströder
  • 307
  • 1
  • 6