To protect my Debian servers, I'd liked to lock access of username ‘root’ to only IP addresses(or ranges) listed in a ‘whitelist’ file. But getting locked out of my server is even worse than getting hacked. And as I travel a lot, I must have a couple good ways add or change the IP addresses in that whitelist file.

1: Is the ssh sshd_config file the best way to limit the IP addresses?
And if I create a new user, example named ‘AltRootUser’ and give him full root permissions, but NOT limited to any IP, then I could login as him to edit the sshd_config file?

2: As a second way of updating the allowed IP addresses, I'm thinking of some secret webforn, where I enter a special password, and a new IP address. Then I could write a script that would take that IP address and add it to the whitelist. Is this doable or are there already any such scripts or tips on doing this?

  • What worked for me: A VPN to login into my remote server when traveling. The other posts about standard 'key based authentication' I of course already know about, as everyone starts with them, but i wanted to try something different and more secure this time: locking all access to a set of ip addresses. This works great. Thanks. – user2671645 Apr 24 '20 at 21:24
  • If one of the other answers helped you (based on your comment) then please upvote and mark it as accepted. – David Apr 24 '20 at 22:02
  • @David: Yes, I tried of course to upvote and mark the correct answer (see my comment under the anonymous guy who mentioned the VPN), but Stackexchange has many barriers and won't allow newcomers to do this. I couldn't even directly reply to your comment. You have to be a regular long time user of this forum to upvote or to even mark which was the correct working answer that helped me. – user2671645 Apr 29 '20 at 7:05

This sounds like an XY problem to me. The real question should be on how to better protect your root account from malicious remote logins and not how to limit access to the root account to only specific IP addresses. While this could be useful in a defense in depth strategy the ways you propose to deal with dynamic IP addresses likely add even more attack surface instead.

I recommend to abandon your specific ideas and instead use other ways to protect your root account from unwanted remote access. Note that the following ways can also be used together for increased protection and that there are additional ways possible for even better protection:

  • Don't use passwords but always use key based authentication. This makes brute forcing accounts practically impossible.
  • Don't allow remote login as root in the first place but login as a normal "jump" user (preferable key based not password based) and then sudo to root or create a tunnel to localhost which you then can use for key based SSH login as root.
  • Use some form of port knocking or SPA (single packet authorization) to temporarily allow access to the SSH service from a specific IP address. This kind of matches your idea but it affects the whole SSH daemon instead only root access and it also uses established implementations instead of some self-made stuff.
  • Although I use all three points you mentioned (to great success and sound sleeping at night), only the first two points are considered best practices. Port knocking is considered security through obscurity. However, having port knocking means connection attempts are dropped at my firewall and not into my SSH log files. – Nathan Goings Dec 19 '19 at 21:00
  • @NathanGoings: Port knocking is not security by obscurity. The security of port knocking is not based on obscuring that port knocking is used but instead on a shared secret (the proper sequence of ports must be used, not just an arbitrary sequence) between the server and the authorized user. Its variant SPA is also based on a shared secret or even on asymmetric encryption where the client proves possession of a private key. – Steffen Ullrich Dec 19 '19 at 21:15
  • If your servers are hosted by most modern IaaS providers you can also setup firewalls using other methods (that don't require first logging into the server). This gives you an opportunity to block all traffic and only whitelist your IP when needed, without the risk of lockout. I would personally consider this a layer of defense on the level with port knocking. However, your first two points should really just be non-negotiable these days. – Conor Mancone Dec 19 '19 at 21:22
  • @SteffenUllrich, I've heard it called security by obscurity before, but your comment is perfectly accurate. Makes me feel less bad about using it. – Nathan Goings Dec 19 '19 at 21:36

This is a situation where running your own VPN can be beneficial, if you have a suitable server for that purpose, and at least one dedicated IP address, that you can add to your whitelist.

  • Thank you, this is the idea that worked for me. – user2671645 Apr 24 '20 at 21:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.