My Linode's logs mention lots of "failed password" alerts. Is someone trying to break into my Linode?

This is certainly a concerning observation, but I hope that I can assuage your concerns with my assessments in addition to providing you some solid security practices for your Linode.

Basic essential security practices for your Linode

Your Linode has a publicly routable IP address, so it will inevitably be prone to receiving a large number of connection attempts. However, these should not be of much concern at all if you implement proper security measures on your Linode such as public key SSH authentication through a limited user account with root account and password-based SSH access disabled, firewalling, and regular software security upgrades on your Linode.

If you log files are mentioning "failed password" authentication attempts, this may be a sign that your Linode is currently allowing password-based authentication attempts. Accordingly, I would strongly recommend determining whether you are implementing public key SSH authentication into your Linode using the above linked tips, then subsequently disabling password-based authentication. No matter how complicated your password is, there is always a chance that an attacker could correctly guess this password.

Public-key authentication, especially with 4096-bit keys, is currently (February 2020) computationally infeasible to crack. As a result, it is a much more secure authentication solution that comes with the additional benefit of not needing to remember a password for your Linode (although your keypair will need a passphrase to unlock, it is possible to use a ssh key agent on your personal device to avoid needing to supply it so frequently). As long as you keep your private key secure, you can be quite reasonably sure that only authorized users are able to access your Linode (which may just be you yourself).

Many of the above suggestions come from our How to Secure Your Server guide, which I recommend reading in its entirety to contextualize the above recommendations.

No system is ever 100% secure -- so think of security in layers

I do want to caveat these suggestions by making it clear that no computer system will ever be 100% secure, except for a system that is completely inaccessible by any possible means. There will always need to be a way for you to get into your Linode, and it's important to make sure that your access methods do not fall into the wrong hands.

Two great ways to ease these concerns are to use a password manager that supports encryption as well as encrypting any personal storage devices where your Linode's SSH private keys may reside. These measures will help keep your security credentials safe even in the event that you lose these devices or that someone steals them.

It is important to consider security in terms of layers that can cover for each other. One example of an additional layer would be by implementing Fail2Ban on top of implementing public key-only SSH authentication into a limited user account on your Linode.

Going further with web server security

If you are running a web server, it is definitely very important to implement TLS encryption on this server to encrypt your visitors' connections. This is especially the case if you are negotiating any sort of account logins or exchanging payment information. Even if you are not, it is not a bad idea to implement TLS encryption since it will likely improve your site's SEO and increase your visitors' trust with your website.

Luckily, it is not too difficult to acquire a free SSL certificate for your Linode's website using Certbot. You will need to have a domain in order to implement HTTPS on your web server if you don't already have one, but it is well worth picking one up not just to meet the requirements of installing a TLS certificate, but also to provide your website's visitors an easy-to-remember name instead of needing to use your Linode's IP address to reach it.

Encrypted HTTP transmissions traditionally use port 443/tcp instead of port 80/tcp, which is the traditional port used for unencrypted web transmissions. Although the Certbot setup process will reconfigure your web server to accommodate this port change, you will need to make sure that your firewall allows connections over port 443/tcp. While reconfiguring your firewall, it would also be a good idea to close port 80/tcp connections to disallow plaintext HTTP connection attempts into your Linode. Of course, it is best to ensure that your web server is properly handling connections using your domain's TLS certificate before implementing this change and possibly locking out visitors.

Cloud Manager security controls

All of the above information concerns the security of your Linode itself, but our Cloud Manager offers a number of its own security-enhancing mechanisms. Aside from frequently rotating your account's password, ideally with the help of a password manager, it is an excellent idea to further protect your account with two-factor authentication to minimize the possibility of intruders breaking into your account and adding services against your will. You may also elect to trust certain devices so that you receive an email alert whenever an unfamiliar device attempts to log into your Linode account.

Final thoughts

Good security practices generally involve implementing layers of security to cover for as many methods of compromise as possible. As as result, there are definitely many more security practices to consider beyond what this answer mentions. Even so, I hope that the information in this answer provides you a good start into implementing good security practices on your Linode.

You write:

While checking out my Linode's logs, I noticed a great number of "failed password" alerts. Is this expected? Is someone trying to break into my Linode?

Are these coming via ssh(1)? If so, and the IP address is not yours or one you recognize, I would certainly assume that an intrusion attempt is underway.

You should implement fail2ban(1) right away. That will shut these down. On my Linode, if a bogus ssh(1) login is detected, the IP addressed is banned (via my firewall) for 30 days…automatically. I can intervene to lift the ban if I want but I rarely do. Here's an example from my fail2ban(1) log from early this morning:

2020-02-12 00:55:28,156 fail2ban.filter         [991]: INFO    [sshd] Found 84.54.118.82 - 2020-02-12 00:55:28
2020-02-12 00:55:28,218 fail2ban.actions        [991]: NOTICE  [sshd] Ban 84.54.118.82

Here's the incident that caused the ban:

Feb 12 00:55:28 <redacted> sshd[13234]: Invalid user arthur from 84.54.118.82 port 38568

The IP address belongs to Uzbekistan Telecom in Tashkent. I don't live in Uzbekistan and my name is not arthur.

-- sw