- Poll: How reliable are ChatGPT and Bing Chat? - Tue, May 23 2023
- Pip install Boto3 - Thu, Mar 24 2022
- Install Boto3 (AWS SDK for Python) in Visual Studio Code (VS Code) on Windows - Wed, Feb 23 2022
Before I outline the solution to the problem, let's first discuss why you might want to log in and why you might not.
Please login as the user "ec2 user" rather than the user "root".
Why you should not log in as root
Amazon disables root login by default because it is supposed to improve security. Of course, the root user is the main target for all hackers and crackers. If remote login is disabled for root, you are safe. That's the theory.
The problem is, of course, that attackers know that on a Ubuntu box, they have to hack the user "ubuntu." And for the other Linux distros in AWS, it is not really hard to figure out which user to target. On most EC2 instances, it is just "ec2-user."
Once this user is compromised, the hacker owns the machine, just as if they hacked root. All it takes is to sudo su. So disabling root does not really improve security that much. Essentially, it is just security through obscurity.
Another argument you often hear is that by requiring admins to log in with a user other than root, they are encouraged to sudo whenever they run a command that requires root privileges. I think that's a valid point. But my guess is that most admins just run sudo su to avoid the extra typing of sudo all the time.
The danger here is that you might execute malware or accidentally damage the system. But in my view, it's not really a strong argument for disabling root altogether. You can still log in with your own user account for common tasks.
Yet another argument is that if several admins manage a system, it is easier to determine who made changes to the system if every admin signs in with their own username. That's a good point, too. But again, this is not an argument for disabling SSH connections with root.
Why you should login as root
I know at least one scenario where you need to log in as root because sudo is not an option. The keyword is SFTP. If you remotely manage a Linux machine, you will often want to use SFTP to edit system configuration files or system scripts which requires root permissions.
Of course, you can also login via SSH and then edit the files with sudo. However, editing large scripts with an editor such as nano is not really fun. It is much more convenient and efficient if you can work with your favorite GUI editor on your local machine.
Some SFTP clients like WinSCP allow you to send a sudo su after login, but many popular tools, such as Transmit for macOS, don't offer this option.
If you want to remotely edit system files in such cases, you have two options for EC2 instances.
Enable root login on EC2 instances
The first option is simply to edit the authorized_keys file in /root/.ssh/. All you have to do is remove this text:
,command="echo 'Please login as the user \"ec2-user\" rather than the user \"root\".';echo;sleep 10;exit 142"
It probably makes sense to leave the beginning of authorized_keys: "no-port-forwarding,no-agent-forwarding,no-X11-forwarding."
Note that you don't have to set a password for the user "root," which you often read in blog posts. I assume here that password authentication is disabled for SSH and that you are working with public key authentication, which I highly recommend. Password authentication is a no-no for servers.
Enable root login on an EC2 instance
Also, notice that whenever you create an AMI from this instance and then launch a new instance, AWS will modify the authorized_keys file, and you will have to remove the text above again.
Create a second root user
If you believe in security through obscurity, you might come up with the idea of renaming the root user. Windows admins often do this for the Administrator account. On Linux, this is not an option because many system components assume that a user with the name "root" exists.
However, you can create a user that has real root privileges. I am not talking about editing sudoers or adding a user to the admin group. This is, of course, the common way, but this does not solve the problem I mentioned above; that is, you won't be able to edit system files via SFTP with this user.
What you need to do is create a "real" new root user:
sudo useradd -m -ou 0 -g 0 sysop sudo mkdir /home/sysop/.ssh sudo cp /home/ubuntu/.ssh/authorized_keys /home/sysop/.ssh/
If you are not working in Ubuntu, you have to replace "ubuntu" with "ec2-user."
The first command adds a new user with the name "sysop." The -m parameter ensures that a home directory is created for the user. With the -u parameter, we assign the user ID 0, which is the ID for root. We need to add -o here because otherwise, Linux will complain that the user ID is not unique. With -g 0, we add the new user to the root group.
Then we have to create an .ssh folder in the user's home directory. In the last line, we copy the authorized_keys file to this folder. This file contains the public SSH key that AWS automatically adds when the EC2 instance is created.
After your first login with the user sysop, I recommend running whoami. You will notice that you are really logged in as root, which means you can run system commands without sudo.
If you work with this option, you can keep Amazon's configuration for the original root user. As we copied authorized_keys from the user ubuntu (or ec2-user), your new root user can connect via SSH.
Conclusion
Apply the changes described in this post at your own risk. Don't blame me if someone hacks your root user.
Subscribe to 4sysops newsletter!
I am curious to learn how you manage your Linux systems. Do you really always type sudo whenever you run a system command that needs root privileges, or do you automatically sudo su? How do you edit and create system scripts? On an SSH console or remotely via SFTP? Please share your views in a comment below.
Great article Michael. Reading this article made me remember the days when I just started learning Linux. We used the same concept of UID/GID being 0 for creating additional users with root privileges. I still prefer using “sudo” command but occasionally use “su -” when absolutely necessary.
Surender, thanks! Yeah, the thing with the UID is very old. It is an awkward way to create additional root users. It is interesting that identity management never evolved in UNIX/Linux like it did in Windows. On the other hand, Microsoft was never able to come up with something like sudo. Until today, UAC is still a joke.
True story. MS keeps focusing on making things visually appealing but we hardly see any improvement at kernel-level though
Well, they tried to improve the kernel, but it is all spaghetti code. Everything depends on everything. That’s why innovation in Windows is next to impossible. They can only do new things by building on top of Windows, but this doesn’t really work well. Think about the mess they created with the Modern Apps in Windows 8.
This is not my area of expertise. Hence, I am curious to know why there is no scope for innovation in Windows?
Ever heard the term DLL hell? The problem is that the OS has been poorly designed from the beginning with little modularity. Changing tiny pieces of code often break totally unrelated components. This is one of the reasons why updates often break the OS. Remember Microsoft was not even able to get rid of all the GUI components in Server Core because they are part of the kernel? I mean how silly is is that to bake the GUI into the kernel? This is what makes it so hard to introduce new features because Windows is at its core all spaghetti code.