How do I change the default username root ?

You can't. However, you can disable root logins using ssh by uncommenting the option:

PermitRootLogin no

and commenting out the option:

PermitRootLogin yes

You should prob set up public-key authentication and disable password authentication. Installing/configuring fail2ban will help mitigate the brute force attack(s).

-- sw

@stevewi Thank you for your helpful response.

I read about fail2ban yesterday but the setup to actually activate say, 3 strikes & you're out for x minutes, seemed to ask me to know more about what I'm doing than I think I know at this moment. New to linux environment & virtual hosting.

Also, it seems to me that root login is essential to tasks I have to do, such as installing cockpit, which is what told me about the bruteforce login activity.

I don't trust solely public-key authentication because I've found it to be inconsistent. At least since I've had a linodes account. Right now I have both Password and key authentication enabled which gives me perhaps the false feeling that I have a "backup".

So, a hidden caveat about installing things in linux is that there are bots devoted just to probe sites like linodes for the next user installation to intiate root username attacks? Since millions of linux & apache commonly installed applications have architecture already well-known with paths mapped?

Such as exist for WordPress users? At least Wordpress allows for usernames outside of 'root'.

It seems weird that in 2022 fail2ban is the one solution that has been created.

Having said that, I will look at fail2ban more closely today. Thank you again!

To add on to @stevewi answer, I sometimes disable SSH login entirely and just use the Lish Console. Lish is not always good for long sessions, but it's great for quick tasks. If I need to I can always login via Lish and re-enable SSH too.

Some responses to your points:

I read about fail2ban yesterday but the setup to actually activate say, 3 strikes & you're out for x minutes, seemed to ask me to know more about what I'm doing than I think I know at this moment. New to linux environment & virtual hosting.

When I used fail2ban, I was pretty unforgiving about brute-force login attempts. I think I had mine set to ban after 1 in 5 minutes. I never had to worry about a mistake on my own logins because I always used public-key authentication.

I don't trust solely public-key authentication because I've found it to be inconsistent. At least since I've had a linodes account.

I've been a Unix guy for a long time. I've used public-key authentication exclusively since about 2000 or so (ssh was first introduced in 1995). It's never failed me (and I've used some of my keys the entire time I've been a Linode customer…since 2013).

Your "backup" is to log in at the console…using lish/glish…to fix whatever mistake you made (and, trust me, if public-key authentication fails it's because you messed it up…not because it messed up all by itself).

So, a hidden caveat about installing things in linux is that there are bots devoted just to probe sites like linodes for the next user installation to intiate root username attacks? Since millions of linux & apache commonly installed applications have architecture already well-known with paths mapped?

Welcome to the internet… I've had brute force attacks start within seconds of spinning up a new Linode. The Chinese, Russians & Indians are really experts at this (also, it seems, so are the script kiddies who seem to populate the Digital Ocean user base).

Such as exist for WordPress users? At least Wordpress allows for usernames outside of 'root'.

You can have other login accounts besides root (aka the super-user). My Linode has several…most of which were created for software I run. The account establishes a context for file permissions and ownership. For example, the account/group pair postfix/maildrop is the account that my mail server users; www/www is the account my web server uses. My account is stevewi/stevewi.

You can become another user using su. The super-user (since he rules them all) is the only only one that set that up. You can run a single command as any user (but, most often, as the super=user) using sudo.

For example, I have a lot of cron jobs to do system maintenance. They run under my account (stevewi/stevewi). If a job needs to manage files/directories that stevewi/stevewi doesn't own, I have to run the job with sudo. I have sudo set up so these jobs don't ask for a password (another thing the super-user must set up).

<rant>

It seems weird that in 2022 fail2ban is the one solution that has been created.

There are others…unfortunately, fail2ban seems to be the most popular (for Linux anyway). For example, there's blacklistd on *BSD systems…a much more elegant solution but Linus thinks it's junk because he didn't think of it first so it's not available on Linux (my Linode runs FreeBSD…and I have blacklistd tied into everything…especially ssh and mail). fail2ban works but it's a sledgehammer compared to blacklistd ;-) fail2ban can only detect problems after the fact and only if the incident gets logged. blacklistd detects the problem at the source when it occurs.

You can also home-brew some intrusion detection using your firewall. Doing that is effective but implementing/maintaining it using iptables is a nightmare (trust me on this)…mostly because iptables is so complex and…ultimately…stupid.

Because iptables is so hard to use, Linux distros have come up with a variety of "friendly" front-ends to iptables to make it accessible to mere mortals (ufw on Ubuntu systems is probably the most notable but there are others). No one in Linux-world wants to really solve the problem -- iptables is too cryptic and too complicated for any but the most-dedicated of users to learn/use.

Linux has long-needed an overhaul in this area. However, given the political dynamics of the Linux Foundation, Linus, FSF and the distro publishers, that's not likely to happen. When it does, you can expect the result to be a major CF…like systemd…so it's prob better to leave well-enough alone. Sad…

</rant>

-- sw

@stevewi
Epically kind and generous response!
Thank you for volunteering all this useful information.