Why is root login via SSH so bad that everyone advises to disable it?

ssh security root

52,138

Solution 1

Why root over SSH is bad

There are a lot of bots out there which try to log in to your computer over SSH. These bots work the following way.

They execute something like ssh root@$IP and then they try standard passwords like "root" or "password123". They do this as long as they can, until they find the right password. On a world wide accessible server you can see a lot of log entries in your log files. I can go up to 20 per minute or more.

When the attackers have luck (or enough time), and find a password, they would have root access and that would mean you are in trouble.

But when you disallow root to log in over SSH, the bot needs first to guess a user name and then the matching password. So lets say the list of plausible passwords has N entries and the list of plausible users is M entries large. The bot has a set of N*M entries to test, so this makes it a little bit harder for the bot compared to the root case where it is only a set of size N.

Some people will say that this additional M isn't a real gain in security and I agree that it is only a small security enhancement. But I think of this more as these little padlocks which are in itself not secure, but they hinder a lot of people from easy access. This of course is only valid if your machine has no other standard user names, like tor or apache.

The better reason to not allow root is that root can do a lot more damage on the machine than a standard user can do. So, if by dumb luck they find your password, the whole system is lost while with a standard user account you only could manipulate the files of that user(which is still very bad).

In the comments it was mentioned that a normal user could have the right to use sudo and if this user's password would be guessed the system is totally lost too.

In summary I would say that it doesn't matter which user's password an attacker gets. When they guess one password you can't trust the system anymore. An attacker could use the rights of that user to execute commands with sudo, the attacker could also exploit a weakness in your system and gain root privileges. If an attacker had access to your system you can't trust it anymore.

The thing to remember here is that every user in your system that is allowed to log in via SSH is an additional weakness. By disabling root you remove one obvious weakness.

Why passwords over SSH are bad

The reason to disable passwords is really simple.

Users choose bad passwords!

The whole idea of trying passwords only works when the passwords are guessable. So when a user has the password "pw123" your system becomes insecure. Another problem with passwords chosen by people is that their passwords are never truly random because that would then be hard to remember.

Also it is the case that users tend to reuse their passwords, using it to log into Facebook or their Gmail accounts and for your server. So when a hacker gets this user's Facebook account password he could get into your server. The user could easily lose it through phishing or the Facebook server might get hacked.

But when you use a certificate to log in, the user doesn't choose his password. The certificate is based on a random string which is very long from 1024 Bits up to 4096 Bits (~ 128 - 512 character password). Additionally this certificate is only there to log into your server and isn't used with any outside services.

Monitoring root access

The comment from @Philip Couling which should have been an answer:

There's an administrative reason for disabling root. On commercial servers you always want to control access by person. root is never a person. Even if you allow some users to have root access, you should force them to login via their own user and then su - or sudo -i so that their actual login can be recorded. This makes revoking all access to an individual much simpler so that even if they have the root password they can't do anything with it. – Philip Couling

I would also add that it allows the team to enforce the principle of least privilege, with a proper sudo configuration (but writing one sounds easier then it is). This enables the team to distribute uncritical better, without giving away the key to the castle.

Links

http://bsdly.blogspot.de/2013/10/the-hail-mary-cloud-and-lessons-learned.html

This article comes from the comments and I wanted to give it a bit more prominent position, since it goes a little bit deeper into the matter of botnets that try to log in via SSH, how they do it, how the log files look like and what one can do to stop them. It's been written by Peter Hansteen.

Solution 2

You're right that root username and X+Y symbol password is cryptographically at least as secure as an X symbol username + Y symbol password. In fact it is even more secure, cause people's names are easy to guess (bots may just try john, mike, bill, etc... and btw: that's what many of them do instead of trying root). And you're especially out of luck if it's a targeted attack, cause if someone wants to break a company's server it wouldn't be a problem to find out the name (nick) of the sysadmin.

And as soon as the attacker has access to the account the sysadmin uses for ssh logins (and then uses su or sudo to do his tasks) he can infect that user's session with a program which will send the attacker root password when the sysadmin types that the next time.

It's any type of root logins which are (or should be) considered bad practices from security point of view. The "normal" user login -> su/sudo chain adds an audit trail. In plain english: it makes it possible to find out who did what.

A special case may be the one, where only one person has root access. In that case using the additional "normal" user won't add much value (at least I never could see that value). But anyway - you're supposed to have a simple user on the system anyway (for non-administrative tasks, running wget, etc ;-) ).

Solution 3

What is so dangerous in enabling root login ( especially with disabled password login )?

The attacker (bot/botnet/hacker) only need to guess the password and has complete control over your system, if you are open to the internet. Also, none of the systems accounts (www-data, proxy, etc.) should be able to login via SSH, for the same reasons.

If you disabled password login (using public key, for example), take into account that whoever gets hold to the private key gets complete control over your system. See why using public key with a user is better below.

And what is the difference between X symbol username and Y symbol password or root username and X+Y symbol password from security point of view in case password authentication is allowed?

The extra username can add a layer of security since: a) attacker should know both pair, username and password; b) in case attacker breach your system it wouldn't have immediate access to a privileged account adding a bit of nuance for the attacker.

In this case public key is also a plus, since:

The attacker needs your public key
The attacker needs the password (or authentication method) to get elevated privileges

Solution 4

It's not exactly bad as long as you take safety precautions. As an example you could install CSF (Configure Server Firewall) and set it the number of allowed failure attempts, so if someone tried ,let's say over 5 failure attempts?, then they are automatically blocked. So the entire first part of the best answerer won't be a problem at all. This happened to me many times, and luckily all the introducers were blocked permanently. I guess for a server it isn't a big problem if you are the only person who manages the server, but of course if there are a lot of system admins, or if you are working in an organization, then obviously don't use root. Also for a desktop PC, I guess using another account is better as there is a security risk since you use a lot of software, but in a server, you don't go for random software that you don't trust, you make sure to keep them as low as much as possible. So the conclusion is, No it's not really harmful if you know how to manage a server properly.

View more solutions

52,138

rush

Updated on September 18, 2022

Comments

rush over 1 year

Everybody on the Internet advises to disable root login via SSH as it is a bad practice and a security hole in the system, but nobody explains why it is so.

What is so dangerous in enabling root login (especially with disabled password login)?

And what is the difference between X symbol username and Y symbol password or root username and X+Y symbol password from security point of view in case password authentication is allowed?
- Admin almost 11 years
  
  Having a root user in most systems is bad in itself, leave alone enabling a SSH login for said user!
- Admin almost 11 years
  
  Root login via ssh is necessary for ehealth-aussie.blogspot.com/2012/01/…. Everything is a compromise.
- Admin almost 11 years
  
  Umm... should we move this question to security? Since the topic lean more towards security then *nix systems.
- Admin almost 5 years
  
  There's an administrative reason for disabling root. On commercial servers you always want to control access by person. root is never a person. Even if you allow some users to have root access, you should force them to login via their own user and then su - or sudo -i so that their actual login can be recorded. This makes revoking all access to an individual much simpler so that even if they have the root password they can't do anything with it.
Alen Milakovic almost 11 years

Good summary. But ssh private keys can get stolen too.
user almost 11 years

+1. This answer could actually boil down to simply N*M > N. Since most *nix hosts have a root user, if you allow root to log in directly from a remote host, the size of the test matrix is the number of passwords to try; disallowing direct root logins, the number of possible combinations multiply with the number of usernames you want to test (and there's still no guarantee that you'll be testing valid usernames!).
Raphael Ahrens almost 11 years

@MichaelKjörling I would add that it is not difficult to get the username, since normally the user name is no secret and I could probably ask anyone to get there's. But it helps against Bots and simple trying.
user almost 11 years

Very few of the passwords I use are less than about 20 random alphanumeric characters (set [A-Za-z0-9] plus a few special characters). 20 such characters (so length 20 out of a character set of 40) gives you on the order of 10^32 combinations. 128 bits of entropy is on the order of 10^38. Not a huge difference, all things considered, and the SSH server is free to implement any kind of rate limiting it likes so it isn't like you are doing an offline brute force attack in that case. There's nothing wrong with passwords, if you can live with them being as difficult to remember as a 128-bit key.
user almost 11 years

I agree, for a targetted attack the username provides no real additional security. However, for the proverbial going from door to door trying the front door door handle (which is more similar to what bots do all the time), it does make the attack significantly more difficult.
Admin almost 11 years

@MichaelKjörling - Yeah, for sure that messed sudo could be as harmfull as PermitRoot ;)
Ludwig Schulze almost 11 years

@michael shh... don't give range, now hackers know that they should use rainbow tables of the order of 20 characters lenght...?
Peter almost 11 years

@Braiam Rainbow tables are only useful if the attacker has access to the hashes to do an offline search. In the case here, the attacker has only the server response to verify against, which is likely limited to only so many attempts — and a lot slower.
BillThor almost 11 years

As M goes up the likelyhood that the guessed userid is allowed root access usually goes down. Although the cracked id can be used to determine the available userids.
Ludwig Schulze almost 11 years

@Peter ups, I messed both dictionary and hashes, but in any case the OP asked why shouldn't he use weak or empty passwords, witch is ridiculous, therefore I came with ridiculous situations why he shouldn't. Sorry that I wasn't interpreted in that way and was taken as FUD.
user almost 11 years

If you feel like trying some 1.8*10^35 passwords (and that's just for the range 18-22 random characters out of a set of 40, and you don't know which characters outside of the set [A-Za-z0-9] I use), I almost said have fun. That's about 117.1 bits of entropy equivalent (2^117.1 ~ 1.78*10^35) and like @Peter pointed out, you'd most likely need to perform an online attack. Storing all those passwords (without resorting to compression) comes out as needing roughly 3.6*10^36 bytes or 3*10^24 TiB (and if that figure is wrong by a few orders of magnitude, who cares?). Keyword random.
user almost 11 years

@BillThor Actually, I would say that as the number of accounts on the host goes up, the probability of any given valid user having sudo access goes down. You still need to find exactly one match with a correct username and password in order to login, and if the system is a one-user host (such as lots of home PCs) the probability of a breached account having sudo access is quite a bit higher than a that on a corporate or ISP's system with thousands of user accounts.
BillThor almost 11 years

@MichaelKjörling Exactly what I meant. On a corporate net the odds a guessed account has usefull sudo access should be less than 1%. On a home computer odds are likely in the double digits or 100%
user almost 11 years

@BillThor M (at least as far as I read it) isn't the number of accounts on the system, it's the number of usernames to try. For each of those, you try the list of N passwords. The total number of combinations to try thus is M*N. If you can try for a username which you can reasonably expect to exist (e.g. root, or an attack targetting a known user account) then and only then M == 1. I see SSH login attacks regularly in the logs; usually, the bot will try a few passwords (or more accurately try logging in with password a few times) for one username, then move on to the next username.
BillThor almost 11 years

@MichaelKjörling Among the people I work with account has a uid has a username. Relationship is 1 to 1 for all three. Other interpretations may apply.
skarap almost 11 years

@Everyone, if the username has X symbols and the password Y there are # of X length words * # of Y length words possible combinations to try. When the username is fixed (e.g. root) but the password is X+Y symbols long, there are # of X+Y length words possible passwords. And # of X+Y length words = # of X length words * # of Y length words
Raphael Ahrens almost 11 years

@0x534B41 You are right and I didn't answered this part of the question. But I used the letter N for the # of passwords in the attackers dictionary and M for the # of users in the dictionary and I would now argue that N is not tiddly correlated with the size of the password(since N does not change for the attacker when the password size could be bigger). So I ignored this part of the question, since in my opinion is that certificates are always better then long passwords alone and it doesn't matter how long your password is it could still be predictable.
Guntis almost 11 years

What is the difference, if the bot guesses a normal user password, but that user enters commands via sudo? sudo uses the same password and you are in trouble again. Of course, you are not in trouble if you switch to the root account after logging in with a normal user.
Raphael Ahrens almost 11 years

This is in fact a problem when you have sudo installed and many users on that machine have the right to use sudo. As I said in my answer "Some people will say that this additional M is not a real gain in security and I can agree that it is only a small security enhancement. But I think of this more as these little padlocks which are in it self not secure, but they hinder a lot of people from easy access." and by small I mean tiny but it is by no means a reason not to do it.
Admin almost 11 years

See unix.stackexchange.com/a/2944/9454
kurtm over 10 years

Peter Hansteen has a number of articles on the "Hail Mary Cloud" - bsdly.blogspot.com/2013/10/… - Good stuff to know about why exposing SSH root login (via password) is bad.
Admin almost 9 years

Changing the port is actually detrimental in many scenarios in itself. And it's nothing more than security by obscurity as well.
Luka about 7 years

my passwords are usually using a lot of characters and signs, so tell me how is this weak: 6alphachar@6alphachar%6alphachar$6alphachar
Raphael Ahrens about 7 years

@Luka it's good that you are aware of the need for long and random passwords. But when passwords start to have a pattern, are not truly random, or are reused at multiple systems your password might be known/guest by an attacker. The advantage of ssh keys is that you never give the private key to anyone you only prove to sshd that you posses it. This means that even the sshd operator can't get that private key from you.
Raphael Ahrens about 7 years

@Luka In addition you might not be the only user of a system, which means it's not possible to enforce good passwords.
Curt over 6 years

What if I have set up a RSA key (with a very strong passphrase for the RSA key) in order to use SSH? Do I still need to disable root login via SSH?
Raphael Ahrens over 6 years

@Curt It always depends. If you are the only user there is no big difference. With multiple users you might want to be able to see who logged in and who used sudo/su/doas to get root privilege. But when the users directly login to root (with different keys) you lose this possibility for accountability. Also with sudo/su/doas you would not only need a secret key, you also need a password to become root (or an exploit), so it is a little gain in security.
dan almost 6 years

@RaphaelAhrens What about a home server that is only used to provide one specific service? The server has access to the internet, but every port are blocked except the ones needed for whatever service it provides. So if someone tries to connect to root@IP:port, they wouldn't even be forwarded to the server properly unless they use one of the specific port forwarded to that server, and if that's the case, I'm not sure how they would connect to SSH talking for instance to a TeamSpeak server 30033 port. I'm just trying to figure out if it's necessary to block root on such a server.
Raphael Ahrens almost 6 years

@dnLL If SSH from the internet is blocked for this server, then you have a mitigation against attacks from the outside and will not have to worry about root logins. But there are still the other services where you should make sure that they are up to date. The question is, what are you trying to protect ,how exposed is it and how valuable for you and maybe others. When it is your private home server the biggest problem you will face are bot nets and crypto miner which don't care about you only about your bandwidth and CPU. These can be repelled with minimal effort. Lastly use SSH keys.
dan almost 6 years

@RaphaelAhrens All my VMs run standalone applications. One getting compromised just mean I wipe it out and reinstall the application, nothing really complicated. Besides, I have a CheckMK monitoring VM so if ressources were used outside of their intended scope, I'd know immediately unless the attacker designed his attack with that in mind. Finally, each VM has the root user (to which I can log in with SSH) and a non-root user to run the application (for instance TeamSpeak). So if TeamSpeak has an exploit, I guess they're technically not (yet) root.
dan almost 6 years

Also SSH isn't specifically blocked from the internet, but I have another VM hosting a VPN server. This one is obviously way more secured than all the others.
Raphael Ahrens almost 6 years

@dnLL Again, the question is, what are you trying to protect, how exposed is it and how valuable is it for you and others. You don't have to do all mitigations, when you have some in place and you consider your risk now minimal, it is acceptable not to do more.
Admin about 5 years

+1 for mentioning fail2ban, as brute force attacks are not just a concern for SSH, but for anything else on the machine. You do not need to get anywhere root or system permissions to "take over" a machine for practical purposes (access private data, use as a file dump, use for phishing, etc.).
vonbrand over 4 years

@aCVn good for you. Most users use 12345 or qwerty
Philippos about 2 years

In the question it says »especially with disabled password login«, which probably means option PermitRootLogin without-password, so all that brute-force password guessing is irrelevant.
Raphael Ahrens about 2 years

@Philippos The question I tried to answer was why do people argue that it is a bad idea to allow direct root access via ssh and the main reason is the brute force problem. As soon as one uses a new, long enough, and random password or a long key pair there is no problem. If you disable root or disable passwords for root the problem is still there but only shifted to the other user accounts. If you have suggestions how to improve the answer let me know. Maybe something like "There is no problem with root, as long as ..."