No SSH root login in EC2 instances - What's the real point?

Question

My question is not about how to get it, I know it can be done by copying the key from ubuntu-user's folder to root's one.

My question is about to understand the motivation after this by default-limitation.

Every article, post, tutorial, etc. I have read explains that it is configured this way due to security issues, to improve it, but since EC2s, at the same time, recommends not to assign a password to the root user, any person who access to the system as ubuntu user has immediate access as root, so I don't understand this motivation.

I have thought that it could also be because many attacks may use root as default user, so it can be a good idea to use another user less common, but again, since the default user is ubuntu in each and every EC2 (the ones with Ubuntu, obviously), this doesn't seem to be a great motive to do it this way either.

Finally, I guess it may be more secure to use ubuntu user instead of directly root just as a "personal firewall", I mean, as long as one has to make a "sudo -i" to become root, one may avoid making some mistakes just because during those 2 seconds one could have the chance to think "Wait, this command I was going to run might not be such a good idea...", and that point I do understand it, but it is the only one which really seem real to me.

Summarizing, my question is whether this last point is the only one I should be worried about in case I allow root login via SSH or I am missing any important/real security point when allowing SSH root login?

Answer 1

Yes you are missing main point. That is that user without password can't login so unsetting root password will prohibit anyone from login as root but sudoers still can get to root shell and execute command with root privileges. And prohibiting root login from ssh is good idea since a lot of attacks try dictionary attacks on users so root/admin/public are quite vulnerable.

Answer 2

There are really a couple reasons that most VM images are configured this way.

One is that users often configure the default user to log in with passwords, even if they're not originally set up that way, and many bots try dictionary attacks on the root user. If the default user is not root, the attacker must also try to guess the default user's name and password, which requires significantly more resources and therefore makes the attacker more likely to be detected when fail2ban is in use. Limiting root logins makes things harder, and security is all about defense in depth.

Another reason is that it's a best practice not to run as root whenever possible. Longtime Unix users will always want to run as an unprivileged user and sudo to root only when needed. This makes mistakes less problematic, and when there are multiple users, it makes auditability easier, since you can see who logged in and did what. Providing a default unprivileged user with sudo privileges therefore configures the system by default in a way that most users will want to use.

If you're configuring the node for your personal use and you're only using SSH keys (that is, password and challenge-response authentication are completely disabled in the config), then it's okay to use SSH as root. Just know that this wouldn't be considered a good practice for a system with multiple users or in a corporate environment.