5

I'm trying to find a good method for hardening a server while allowing automated remote management via ssh (ansible).

The popular choice is login with a normal user and then use sudo, but this has some problems:

  • Passwordless sudo: this is a no-no. It's just as if you allowed direct login to root.

  • Sudo with password in a file somewhere. Don't like the idea, writing the password in a file opens a world of possible attacks.

Then I've seen some people suggest allow root login via ssh but only from localhost. At first sight this seems like a good idea but after a bit of thinking it's not a good one. Once an attacker gets into any account in the machine s/he can attack root's ssh as if doing it remotely. It's like putting a second lock on a security door. It will take longer for the attacker to break it but it won't be any harder.

It can even make it easier because the attack surface is greater. If using SSH Agent Forwarding to enter root via a normal user, an attacker could modify the user's login scripts to use the forwarded authentication to gain root and then restore the login scripts and clean up the logs so the user has no clue to what has happened.

What would you suggest?

Toni Homedes i Saun
  • 183
  • 8
  • 3
    Passwordless sudo isn't terrible, if you only allow user access via key based auth, and properly secure the keys. In terms of risk, I'd put key-based user/passwordless sudo as more secure than password-based user/passworded sudo, especially in the common "sudo requires user password" configuration. – Matthew Feb 21 '17 at 09:45
  • Thanks Matthew, I was thinking of something similar, having a dedicated "ansible" user and it's keys in a USB crypto token. But I keep thinking that, at the end, this is not safer than exposing root's account to key-only login. – Toni Homedes i Saun Feb 21 '17 at 09:52

1 Answers1

1

I would use a Match block in the sshd_config file to only permit direct root login from the machine(s) used for remote management. If those machine are on the same local network, IP spoofing should not be possible (at least from a remote machine). Something like

Match Host my.admin.machine
    PermitRootLogin prohibit-password

That way, root login is normaly denied from any machine other than my.admin.machine, and simple password login is not allowed from there (only key).

Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84
  • Thanks Serge, but the servers are remote VPSs. Not possible to do this, though I keep the idea for possible use in in-house servers in the future. – Toni Homedes i Saun Feb 21 '17 at 11:01
  • @ToniHomedesiSaun Even in case of remote admin, provided the servers authenticate themselves through their server keys, a root login would require 2 different keys, one for the server authentication, and one for the login itself. – Serge Ballesta Feb 21 '17 at 11:14
  • Sorry, I don't understand this last comment. What do you mean by "_the servers authenticate themselves through their server keys_". The checking of the public keys in the `known_hosts` file? – Toni Homedes i Saun Feb 21 '17 at 13:08
  • @ToniHomedesiSaun Exactly. But ssh-sshd not really check the public keys, they use the public key in known_host to confirm that the peer actually knows the private key corresponding to the public one. That's the reason why I call that *server authentication*. – Serge Ballesta Feb 21 '17 at 13:28