Hacker News Reader

You fail to understand that true security is not about passwords but control.

Disabling remote root login,

1. cheaply reduces attack surface

2. necessitates assigning administration rights to specific persons and roles.

3. greatly increases command visibility and value of audit trails.

4. combines extremely well with disabled terminal shell over SSH

5. can reduce (unnecessary) system resource usage.

Etc.

There are very good reasons why this practice is standard. Unless you are specifically creating a test or honeypot box of some kind, you would be foolhardy to ignore it.

You fail to understand that true security is not about passwords or control; true secrity is about risk mitigation.

Control is an ignorant tyrants last redoubt. Security is only about: identifying risks and dealing with those risks. All other messures are worthless as actual security objectives.

I am not arguing with you in priciple, only in particular. All of your points are well taken, to reduce risk, but not to control.

As the other comment say, Security is about risk mitigation. Risk in turn is about identifying threats, and attack surface is avenues where that threat might cause damage.

The problem I have with the articles claim is that limiting roots access in ssh is not improved security. It does not acknowledge the threat or attack avenue at all, but rather tries a blind approach. The threat is script kiddies. The attack avenue is bad passwords combined with password authenticated use of ssh by root. One can then either fix A) the password, or B), the access root has in using ssh. I pick option A and thus have have good passwords that secure even against internal users, rather than having bad passwords and limiting roots use of ssh. Having good passwords, and disable ssh for root is redundant and a expensive limitation for no security benefit. Having bad passwords and disabled ssh is bad security practice, as bad passwords should by policy be impossible.

> 2. necessitates assigning administration rights to specific persons and roles.

If you need to have different assigned administration roles for a single installation, and guarantee a correct audit trail, you should look into physical tokens or at least a kerberos+ldap setup. "root" user should then not exist as something that anyone should use. however, if you do not care about guaranteed audit trail (and to be honest here, the common use case does not require kerbros+ldap setup), you can add something like environment variables to indicate which user is logged, and ask administrators to document changes to the system.

> 5. can reduce (unnecessary) system resource usage.

This goal can be mitigated in several way. Thus in a honest discussion, this should be the target of it and not the pretense of increased security.

.. and it saddens me each time I read a comment like this. It's best practice to disable remote root login. A whole industry supports this.

And, yet, the best practice seems to require an user account with full sudo priviledges.

If you know the difference between that and root, please explain it, because I can't see any.

Well root is the default full access account. It is a bit easier to root@serveraddress and brute force in that way than needing to guess which account in the system has sudo access.

It also becomes easier to detect when someone is attempting to break in when you can see logs of common user names in a row fail to log in.

I don't do much admin outside my hobby boxes. One guess would be, excluding the ability to enter a root shell, each sudo command is logged so you know who ran it. If the user is root, then it's harder to know what they did while they were root.

Disabling root also means you now have to guess the username and the password instead of just the password.

If someone logs in directly as root, how do you track root access? Given that you should be discouraging root use and using sudo or scripts to automate admin tasks, why are you encouraging admins to log on as root?

Discouraging root usage is common in desktop and laptop environments, and for developers on production servers. For admins on servers, root use is basically required for all commands, and sudo would not improve the security at all.

Commonly, I track access through environment variables (configuration on the ssh client), and documentation that each administrator do after finishing a task. As one should not recruit administrators that do rm -rf /, tracking (blame) is of an lesser importance and documentation a much higher one. If more was required, I would go with kerberos+ldap approach without anyone using local root user accounts at all.

I am the admin. I use the root account as little as possible. I do employ admins that don't rm -rf / by employing admins who don't hack on live as root. Knowing who does what is paramount for resolving problems particularly in admins' work practices.

If someone logs in directly as root, how do you track root access?

By their SSH-key and IP address (both of which are logged to a remote syslog-server).

Given that you should be discouraging root use and using sudo or scripts to automate admin tasks, why are you encouraging admins to log on as root?

That is a false premise. I'd never encourage anyone to use "sudo" because it's a source of errors; people get the escaping and context wrong all the time, doing things that they didn't intend, and wasting precious productivity on getting the incantation just right.

It also doesn't add any meaningful security, it's a red herring.

If you need a dependable audit-trail then sudo is worth zilch. In that case you're looking at SELinux, auditd and friends.

If you don't need that trail (which is most people) then sudo is a ball on a chain and a false sense of security. Local privilege escalation exploits are dime a dozen, any shell-account can be upgraded to root by a dedicated attacker anyway (sometimes via sudo itself, as seen in in the recent sudo exploit...).

Oh, and let's not forget: If you enable a user to do anything meaningful with sudo then that normally includes giving him a way to write arbitrary files as root...

Logging the ssh key used sounds interesting - not something I've tried before.

I think you're doing something wrong with sudo. I'm not talking about "reentering your password" in the Ubuntu or Mac sense. I'm talking about giving access to specific limited commands.

And what distro are you running where local privilege escalation is common?

I'm talking about giving access to specific limited commands.

By definition the set is either so limited as to be essentially useless, or it opens (usually multiple) straightforward paths to a root-shell. Pretty much all sudoers-files I have seen fall in the latter category ("but he can only write the apache config-file!").

And what distro are you running where local privilege escalation is common?

https://www.google.com/search?q=linux+local+privilege+escala...

"only write the apache config-file" Ha!

Local privilege: yeah, that's a lot but over a long time span and none should be current on decently maintained box. I've never even seen anyone attempt a 0 day on my boxen.

> Logs wears on the hard drive, so one might want to install fail2ban to lower the number of writes to it.

Or change the ssh port.

Another "security through obscurity" pointless trick. If I'm attacking your server and it's not running SSH on port 22, it's a very short matter of time until I've found it anyway.

I don't understand this objection.

If you've got a physical safe that you keep money or valuables in, do you put it out at the kerbside so people can have a go at cracking it, or do you hide it inside in an obscured location to make it more difficult to have a go?

Surely it's the same with services on your servers, why needlessly advertise their presence. It's a tiny veneer of security but it is still more secure surely.

Sure. It's only meant to stop automated script-kiddie attacks that target all open SSH servers on the internet. Less logs, less disk usage, ...

Wouldn't the script-kiddie through those hosts into a queue to run a more advanced port scan on? I mean, I see your point, but it seems highly useless compared to, say, simply disabling the password based authentication.

Why would they bother? Script-kiddie is just playing the numbers, any machine with a slightly non-default configuration is not worth the effort.

Disabling password authentication is better for "real" security, but doesn't stop those dictionary attacks spamming your logfile. (I still feel there should be better solutions to that problem than changing the port though)

> I still feel there should be better solutions to that problem than changing the port

Well, there is port knocking. http://www.thoughtcrime.org/software/knockknock/

I guess my response to all of these is... using key based auth is so much more secure than changing the port that changing the port seems to me, completely, pointless. Especially considering that:

- password auth = me having to type my password everytime, likely to have a less secure password

- key based auth = me never having to type it in, with a key length so long that it's completely inconceivable it'll be cracked or collided or brute forced

and then when you change the port, the only "advantage" I get is that I now have to remember the port because they're already not getting in by virtue of key-based auth.

> using key based auth is so much more secure than changing the port

Is it really? Once you get to a sensible password length (say, >14 characters) haven't you effectively made brute force and dictionary attacks impossible anyway?

> password auth = me having to type my password everytime, likely to have a less secure password

If you use a password often enough, I find the time difference between an 8 character and a 16 character password immeasurably small. It's all muscle memory anyway.

>key based auth = me never having to type it in

Perhaps I'm clinging to a false sense of security, but I find the idea of anyone with access to my local machine being able to access my server with 0 additional credentials really disconcerting.

Perhaps in the theoretical world if they can access your machine it's game over anyway because they can install a keylogger. In the real world, I think there's a fairly large population of people who might access your server who wouldn't/couldn't install a keylogger to steal your password.

Your private key should have a strong passphrase. I agree that using a passphrase-less key is bad practice. As for keyloggers, once they obtain your password, they have succeeded. But after obtaining a key's passphrase (which you normally only type in once a local session if using ssh-agent), they still need the key, which may or may not be marginally harder. It's still another step to overcome. So, even if it can be shown to be only a narrow improvement over passwords under certain circumstances, it's a big win in convenience and even security under normal circumstances if done properly. Give it a try, finetune your ~/.ssh/config and you might end up loving it.

> but I find the idea of anyone with access to my local machine being able to access my server with 0 additional credentials really disconcerting.

You could hook whatever locks your screen to also clear your ssh-agent then. This is probably something like alias xlock=$(ssh-agent -k && xlock) in linux.

You do lock your screen, right?

The answer is really easy: You should do both.

Disable password auth for root, and change the SSH port.

The advantage of changing the port is to reduce the spam in your logs. Checking your server logs regularly really does increase your real-world security.

Imagine how long it would take to scan every port between 1 and 65535 on millions of machines.

Versus how long it would take to just try port 22 on millions of machines.

It wouldn't stop a determined hacker for more than a few minutes, but it will reduce the number of automated attacks on ssh essentially to zero.

this. Everytime I check my logs there's tons of failed tries to port 22 yet none to the port ssh actually runs on. Which keeps the log with failed logins clean.

They don't seem to. Plus, if they hit more than 5 ports their ip gets blocked. Plus it keeps crap out of my logs...

“correct horse battery staple” — the new hacker’s choice of password.