For a node, is no root password feasible if root access is disabled for SSH?

I would like to explore the viability of operating a node with no root password.

As a background, some sources suggest that the administrator should disable root access by SSH, in preference to root access being obtained by elevating permissions once connected to a shell as a regular user, that is, for example, by invoking sudo. Other sources suggest that the choice offers little advantage over a strong root password, or a requirement that a private key be included among login credentials passed by the client.

It may be noted that any attacker who has gained access the account for the cloud infrastructure may easily compromise the system, by changing the root password with the automated tools, and then logging into the online system, or by mounting the file system offline and performing surreptitious modifications.

Since access to the terminal is available to everyone, and only to those, also with access the cloud infrastructure, it may seem unnecessary to keep a root password, as long as root access is disabled for SSH.

Meanwhile, remote access may be available through a regular user who given permissions to elevate privileges, that is, is designated as allowed to invoke sudo.

On balance, it may seem as though maintaining a root password is an annoyance to administrators that provides no particular additional security.

The one pitfall I notice is that somehow the system should be configured such that a root shell may not be obtained by a regular user invoking su but providing only an empty password.

I am seeking opinions and advice. Is maintaining a root password unnecessary and unhelpful, if root access is disabled for SSH?

3 Replies

Linode's recommended security practices for compute instances is that it is more resilient if you disable root, and assign root privileges to a limited user:

This has a few benefits, one of which being that it adds an additional layer of security (needing to know the user), as well as complicating automated brute force methods which typically only try to access compute instances as root.

Granted, all of your compute instances on your account are subject to being compromised if your account itself is compromised, as you said, however this too can be limited in likelihood if you utilize 2-factor authentication:

Personally, I have limited users set up on all my compute instances, disable root login, use strong passwords with significant character complexity that are randomly generated by 1password, and for my Linode account I use two-factor authentication with Duo.

I suppose you could take it a step further and say that my account could be compromised if my email address were compromised, but I also have 2-factor authentication set up with my email provider, so that is also unlikely.

Not that my security practices are perfect-- there is still the need to maintain up-to-date software on the compute instances themselves to ensure they are resilient to future threats, but with compromises of any kind, it is more a game of numbers (am I an easy target?) than anything.

The short answer to your question, however, is: No, it is not necessary to maintain a root password.

Technically you could just disable root immediately after creating your compute instance, and if you ever needed to access your machines via root, you could just reset the root password via the Linode Cloud Manager, and then Access your machine via LISH. The only caveat here is that you would need to power down any instance which you needed to reset the root password on, which would impact server uptime, and for some situations that would not be ideal.

I hope that helps!


A central idea underlying my question was a scenario such that root access to the system would be possible directly from the console (e.g. Lish), without a password.

The reason for the scenario seeming coherent is because entering the root password on the console would provide no additional security beyond that already provided by the infrastructure.

Anyone who may access the infrastructure account may easily gain complete power of the node.

There are plenty of situations where access to a Linode account wouldn't necessarily mean access to resetting root passwords, and by extension, access to services on that account. Let me give you an example:

I create an account with many users for a team of developers with read-only access to services on the platform. I don't want developers having the option or ability to remove services without my approval. Because of this I give them Read Only access to my most important instances.

Read Only privileges means: The user can view the resource and all of its associated information typically visible within the Cloud Manager, however they cannot otherwise interact with it.

As the owner of the account I have Read-Write privileges: full access to the selected resource and can make any changes that only an administrator is otherwise able to. This includes resource deletion, cloning, and all other applicable edits. The user also receives an email notification when a ticket is created or updated for this resource.

More information on users and permissions in the Cloud Manager for specific services:

With this being the case, it is entirely possible to give specific developers root access to specific compute instances, while also maintaining the security of that compute instance as a whole by denying the ability for any of them to reset the root password in the Cloud Manager by way of Read Only user access.

In any case, root passwords are a required field when creating a compute instance on the Linode platform, so unless you disable root logins, a password would be unavoidable.

I think the basic Idea that you have is, "if this aspect of security is compromised, then the whole thing is compromised, so what's the point?" And while I can understand the premise, the goal of security is to have multiple layers to prevent breaches; Unique Users and passwords, permission levels for users, file-level encryption-- having each of these components in place is fundamental to a strong and resilient security apparatus, and limiting fallout, so if the concern is having your Linode account's superuser compromised, then two-factor authentication and using secure tunnels when on public WI-FI are probably the best thing you can do to secure your account.

Hopefully that makes sense and gives insight into some of the rationale behind how the root password could/can provide additional security beyond the infrastructure.



Please enter an answer

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct