This is the most ridiculous thing I have ever seen...
|
| Author | Content |
|---|---|
| JaseP Sep 19, 2015 5:11 AM EDT |
This is the most ridiculous thing I have ever seen... Totally inadvisable. Remote root logins are the last thing you want... Even less desirable than MS's news of a new Linux based operating system. |
| gus3 Sep 19, 2015 12:03 PM EDT |
Uh, no. I need remote root for certain rsync tasks. The latest update of OpenSSH caught me very much by surprise. |
| AwesomeTux Sep 19, 2015 12:22 PM EDT |
It is a very bad idea to have root SSH login enabled. It makes brute-force and dictionary password attacks on the root user very possible. Having an attacker gain access to a normal user is one thing, having an attacker gain access directly to root is another. Now, if the SSH isn't facing the public, it's less of an issue. Though, any Windows systems on your network could still potentially have a virus that targets SSH servers on the network. Root login should just be disabled, your SSH is more secure that way. |
| gus3 Sep 19, 2015 2:07 PM EDT |
1. Windows will never touch my network again. Ever. 2. The network doesn't touch the public Internet. 3. If it did, all incoming connection attempts would be blocked. 4. My root password is a combination of letters and digits that have meaning only for me. It is found online in an assortment of contexts, none of which is a password. 5. An NFS root mount needs all UID/GID metadata preserved, including root, for privileges to work (root_squash isn't an option for NFS root). Rsync to root-owned directories through SSH means having root login through SSH. This is my setup. It is a real, working setup. Blocking root through SSH interferes with its administration. |
| mbaehrlxer Sep 19, 2015 2:09 PM EDT |
what i would like to be able to do is to allow root login via ssh from localhost only. this is to allow me to replace sudo, which is hard to set up to work with ssh keys, and also doesn't provide a genuine independent root login session (as it shared some of the users environment) greetings, eMBee. |
| penguinist Sep 19, 2015 2:11 PM EDT |
I know that the "common wisdom" is to not enable root logins, but I have to side with gus3 on this one. My backup strategy uses a certificate-based root login along with rsync and hardlinks to perform unattended scripted nightly backups. The root access is needed in order to backup all relevant files on the target systems including system configuration files, logs and multiple user directories. This does of course mean that the backup server is a critical element since it holds the certificate that gives access to all servers in the backup list. Of course, the backup server is not running Windows (duh), is buried deep inside multiple layers of firewall, and supports no user accounts. Ten+ years of nightly backup experience with this configuration has shown me that the system is robust. |
| AwesomeTux Sep 20, 2015 1:54 AM EDT |
To gain entirely root login, use "su -" or use SystemD's new "machinectl shell". It would be wiser to add another user to the system for SSH, this user would just have to have the necessary permissions to read root owned directories and perform certain root privileged tasks, but not be allowed to install / remove software, delete system files, etc. But, again, if the SSH isn't facing the public, and there really is no Windows systems on the network, meaning no wife or kids using Windows, or a neighbor on Windows using your WiFi (with or without permission), then it isn't a problem to allow root login. But it really is not the preferable setup in any other situation. |
| AwesomeTux Sep 20, 2015 2:00 AM EDT |
By the way...gus3 wrote:4. My root password is a combination of letters and digits that have meaning only for me. It is found online in an assortment of contexts, none of which is a password. This is irrelevant. Unless the password is, say, 20 or more characters long, a brute-force attack can crack it in a matter of milliseconds, no matter the letters, digits, punctuation, and other characters. And this is getting faster and easier as hardware becomes faster and cheaper. |
| nmset Sep 20, 2015 4:20 AM EDT |
So in brief, root login can be useful as per context, that's why SSH devs have left this option persistent. |
| JaseP Sep 20, 2015 11:27 AM EDT |
I stand by my original statement. There is nothing that you couldn't do through either sudo or su from a properly configured account, and/or through scripting. I don't even have login enabled root accounts active on my machines, locally. Remote root logins are just sloppy, insecure sysadmin practice. Sorry if that offends, but it's the truth. |
| kikinovak Sep 20, 2015 1:33 PM EDT |
@AwesomeTux. "Unless the password is, say, 20 or more characters long, a brute-force attack can crack it in a matter of milliseconds." On my Slackware server (radionovak.com), root access is enabled AND the password is less than 20 characters long. Now let's see how many milliseconds it takes you to break in. :o) |
| gus3 Sep 20, 2015 2:52 PM EDT |
More importantly, how many milliseconds it takes to get in undetected. A brute-force attack can be either fast or stealthy, not both. |
| AwesomeTux Sep 20, 2015 3:11 PM EDT |
kikinovak wrote:Now let's see how many milliseconds it takes you to break in. :o) Many ISPs and DNS servers block people for multiple failed SSH attempts, and normal web servers often blacklist IP addresses attempting brute-force attacks as well. Needless to say, I wouldn't attempt a brute-force attack myself. However, suffice it to say, root login is disabled by default for a reason. Just like any system that uses passwords, a brute-force attack is always a possibility. |
| penguinist Sep 20, 2015 4:59 PM EDT |
First, let's keep certificate root and password root distinct. These are really different issues. I don't think you will live the millenia required to brute force my 8192 bit ssh root certificate, even though I've now told you its length. Secondly, I don't know what use case would need password root, but I think the "milliseconds" estimate on that brute force exploit was making unrealistic assumptions. i.e. - one would ideally be collocated with the target server in order to get millisecond latencies even for a single attempt. Let's do some math: I'll make it easy, let's say you only use lower case characters and no numerals or special characters on a short 8 character password, and let's say that you know in advance that the password length is 8, But let's assume that the password is randomly chosen so that a dictionary lookup or similar shortcut would fail. Then the total number of possible passwords is 26^8 = 208827064576 and let's say that on the average you will need to try half of those before you break the code. That brings us to needing 104413532288 tries on the average. Now let's calculate how long it will take for each try. I have a high performance server located pingtime 47ms distant from me. Quick test against this server shows that it takes 720ms of clock time to do a successful ssh login to this server. An unsuccessful attempt takes longer, but let's take 720ms as our estimate for one try. Now we can calculate how long on the average our brute force attempt will take. 104413532288*720ms = 26**8/2*720e-3/60/60/24/365 = 2383 years. Did I get the math right? Add both upper and lower case and numerals and special characters to the pasword and the numbers get even better. Certainly in that amount of time, someone will notice the exploit and give it a mercy killing. :) I think the real danger with password login is with poor choices: 1. the use of one or more dictionary words 2. inadvertent disclosure of your password (like asking google to search to see if your password is recognized! or using the same password on your Facebook account.) |
| AwesomeTux Sep 20, 2015 6:25 PM EDT |
penguinist wrote:First, let's keep certificate root and password root distinct. These are really different issues. I don't think you will live the millenia required to brute force my 8192 bit ssh root certificate, even though I've now told you its length. You would never try to brute-force the certificate, that'd be absurd. penguinist wrote:Secondly, I don't know what use case would need password root, but I think the "milliseconds" estimate on that brute force exploit was making unrealistic assumptions. i.e. - one would ideally be collocated with the target server in order to get millisecond latencies even for a single attempt. I was assuming by a non-public-facing server that implied an actual physical server on the same network as the attacker. Brute-force over the internet might take considerably longer, the brute-force is still lightning fast, it's just the network speed is too slow to make a practical number of attempts. It's still possible though. penguinist wrote:Now let's calculate how long it will take for each try. I have a high performance server located pingtime 47ms distant from me. Quick test against this server shows that it takes 720ms of clock time to do a successful ssh login to this server. An unsuccessful attempt takes longer, but let's take 720ms as our estimate for one try. Now we can calculate how long on the average our brute force attempt will take. 720 milliseconds? Something's wrong there. To be clear, an attacker only has to connect once, and try as many times as they like. After the connection, I believe all of the password validation work is being done on the server, by the server. That basically means no latency other than the delay the attacker would have after each attempt. Some servers, maybe even most, have a delay for failed logins as you mention. That is a far more effective argument for why a brute-force attack is basically impossible. However, the delay for failed logins is still not very effective. Any estimate you make, you can go ahead and divide it by 100 or even 1000. Attackers don't try one password, one connection at a time. They make their hundreds of initial connections, and then try 100 or 1000 passwords every X milliseconds. So let's say you have a 720 millisecond delay for each login. 720 * 100 = 72 seconds. The attacker now has 100 SSH sessions open waiting for passwords. The attacker can make 100 attempts, this may be enough for a dictionary attack already, but let's say they fail. The server waits for, say, 5 seconds. I think that's the default for most systems. From there they can now make 100 attempts every 5 seconds. This brings the time needed down to about 165 years, still not possible. However, I'm using your math. In a more likely situation a dictionary attack would probably succeed in a couple hundred tries, or if the attacker is a really smart cookie, the passwords are "randomly" generated but still follow some rules, like they use real words with or without number substitutes, like 0's for o's, and they use years and real dates not just random numbers, etc. Attackers are very smart and have a lot of computer power at their disposal. They aren't restricted to one randomly generated string per connection. penguinist wrote:2. inadvertent disclosure of your password (like asking google to search to see if your password is recognized! or using the same password on your Facebook account.) This is a strong enough argument against root login by itself. I would add that logging into your server as root in anyway that isn't over SSL is a sure-shot way of disclosing your password to an attacker. |
| penguinist Sep 20, 2015 7:48 PM EDT |
So to summarize, 1. if you are setting up for an rsync/ln backup script and need a root login, you should use a certificate not a password login, because as AwesomeTux points out, it would be absurd to try a brute force attack on a certificate. 2. and please do not set up a password root login if you handle your passwords stupidly. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!