Home / server / Questions / 292060
In Process
ento
Asked: 2011-07-20 17:34:42 +0800 CST

How to structure the "authentication graph" of a group of frontend/backend servers?

  • 772

I'm taking over a bunch of servers as a newbie sysadmin, which include a frontend web server, and several backend servers that hold databases that include private information of the users of the web service.

For a starter, I disabled SSH password authentication. I'm wondering what else I should take care of, in terms of login authentication, to secure the servers with reasonable strength (first priority), and also to ease the task of future administration issues (second priority).

Question 1: Is it recommended to setup a "stepping stone" server, like in diagram (2) below, which will be the only server with port 22 open to the wild? Will it make the backend servers more secure?

(1) Flat-shaped -- no stepping stone (current setup)


[dev machine] - pub key auth - [Frontend]*
 private key A                  public key A



[dev machine] - pub key auth - [Backend]*
 private key A                  public key A

(2) Star-shaped -- with stepping stone


[dev machine] - pub key auth - [S- stone] -    ?    - [Frontend/Backend]*
 private key A                  public key A



Question 2: In case of this setup, which authentication method is recommended for internal login?
                         (a)   use another key pair: priv key B - pub key B
                         (b)   use ssh-agent
                         (c)   reuse key pair A: put priv key A to the s- stone
                         (c)   use password auth

Note: "authentication graph" in the question title is a made-up word. I'd be glad to know if there's a term for this kind of problem -- which server to allow login from for which server.

security authentication ssh

2 Answers

  1. I don't think a bastion host is a net benefit. If you login to it the same way as you get into the backends, there's no benefit (if an attacker pops the bastion, he's all-the-way in), and if you need to login to the bastion differently, it's a massive administrative frustration and sooner or later you'll work around it to be more productive, and your security just went out the window.

    On the other hand, having everything hanging out on the Internet for anyone to take a poke at is a bit of an unnecessary risk. The solutions I've deployed in the past include:

    • Limiting the source IPs: Neat in theory, until your ISP renumbers your home connection or you urgently need to get into a server when you're on the road.
    • Port knocking: Cute in theory, but is more useful for keeping your auth logs clean than providing any real security. Also very embarrassing when you forget the port knock sequence.
    • VPN: Good security, especially if you have to use unencrypted protocols to the backend servers every now and then (damn you, IPMI), and can provide good, strong auth if you use PKI (yay openvpn!). Downside is that your client config gets more complicated.

    There's no "best" solution. I like VPNs, but YMMV.

    • 2

  2. A gateway box ("stepping stone", "bastion host", etc.) is a good idea as it limits the attack profile: Rather than having many machines' SSH daemons exposed you only have one.

    That said, as womble pointed out if you're using the same credentials to log in to the "stepping stone" and all the servers behind it you aren't getting a net gain in security - One key/password/etc. gets compromised and they can get anywhere they want.
    You should implement discrete authentication credentials (separate key for the "stepping stone" box versus the stuff behind it) at a minimum, and should consider the other techniques womble mentioned (specifically source IP limiting and/or port-knocking) as additional layers of security.

    Note that if you take the VPN approach you usually rely on the VPN as the security provider (taking the place of a "stepping stone" host).

    • 1