ok so i thought i would shove a quick techy thing up while its fresh in my head. this post i think is great when you are in an environment where you have to compromise on security and ease of use. I have to admit though, this tip is not my own i read this originally on Jordan Bedwell’s (Envygeeks) site however the site no longer seems to be available and i havent yet found it anywhere else. So i am posting this up for all to benefit as far as i am aware Jordan should recieve credit for it – feel free to correct me if i am wrong.
This article follows the logic that normal users will want to use a password and do not use keys. The truth is folks, most Engineers and Admins have to put up with people who don’t understand key based authentication, and it’s our job to come up with creative ways to secure the server while not being obtrusive to their lives.
Recently we had a spur of clients ask us to enable root for them. Mostly because we don’t allow our clients to root into most of our dedicated servers, we force clients to login as a normal user and then sudo -i into root (root login is completely disabled, no password so no ability to login ~ no su). The problem was, even though we had fail2ban, this would not stop a large bot-net attack as fast as they could cycle, unless we got really strict, which we can’t because of a catch 22. Either be real strict and have to deal with abnormal amount of requests that we could not cover feasibly while keeping up our goal of being efficient or reduce security a tiny bit and come up with a user-name that would be as hard to guess as the password making it twice as hard to haxor up our stuff. The problem here is, as we saw more and more root requests come in and we rejected more and more unlocking (we always tell them they can enable it themselves but we will not cover it ~ if our investigation concludes a brute force into root) we started to take this as a challenge. Not really since we already knew how to do it.
We are not any different than your host, we generally deny any other way for the sake of sanity. Not really, we are very creative, we just like to keep things uniform too. The truth is, most hosting companies tell you it’s insecure to enable root, and they are right, and wrong. The problem is, we are not a hosting company, we are the company that teaches the engineers at the hosting company how to do their job and does their job when they fail to hard to do it. The real truth is enabling Root is only as secure as you make it and most engineers and admins or at least most that know how to do their job, know ways to enable root while keeping it rather secure from brute force attacks.
The How-To and FixThe dirty dirty, most of you already know it, add a key to root, and then switch the PermitRootLogin, now, before you talk, go on and say what you’re going to say, and then shut up and listen closely. We will not use yes or no for this variable. We will actually use a different value. Lets look at our decked out SSH_CONFIG and see if you can figure it out:
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
That’s right boys and girls, we simply change PermitRootLogin to without-password and boom, we can now only login using our key. The good part about this is too, a flaw by design is it still shows a password dialog which can be a nice little trap for idiots who try to brute force into the server or idiots who just want to try and see if they can “guess” the password so they’ll still be caught by fail2ban but will never be able to get in, because interactive passwords have been disabled, unless they magically get in and add their key to root. Go on now, start generating your 8K RSA keys and enabling root only by key login.