Thanks! I would assume that there are lots of people with open port 22s. Was I just one of the unlucky ones, or do they get everyone? And what would they try to do with my machine?

Literally everyone. Have some application running on port 22 and you can watch chinese IPs connecting to it within hours.

Note that because of this, it's foolish to be allowing password authentication. Your sshd should be configured for pubkey auth only. Then (assuming no pre-auth vulns, which IIRC have not occured in decades and probably never will due to proper privsep design) you don't have to worry about the brute-forcing ever succeeding.

On my personal servers I change the SSH port as well, since that stops 99.99% of attacks

This question has me imagining a large community of people with Raspberry Pis having open SSH ports with insecure (but not obvious trap) passwords to accept these SSH scans and send back gigabytes of garbage to gum up the scanners. I imagine it would make random attacks a lot less desirable to try if you were likely to spend a lot of time sorting through garbage.

@Turksarama A honey bucket, as it were.

@FredStark I would be inclined to say it's just security through obscurity, but I know you are 100% correct

@MechMK1 Security through obscurity isn't bad per se, it just shouldn't be the only line of security.

I'm wondering, with the increasing prevalence of IoT devices ru(i)nning our lives, if Linux vendors may have a moral responsibility to ensure that their distributions are setup with randomized configurations (e.g. each port-number for a non-interopable externally-accessible service is generated from a crypto-RNG) - especially with SSH there is no need for everyone to run on port 22.

@TheD A "non-interopable externally-accessible service" is somewhat of an oxymoron, since the whole point of having an externally accessible service is interoperability. Besides, simple port scans are trivial and won't add much to the time it takes for their botnets to scan services anyway.

@pipe I'd argue that SSH is not an "interopable" service the same way that HTTP or FTP is. While it's interopable insofar as the sshd will conform to the SSH specs, only users already authorized to access a system will have credentials to connect to the computer, so just add the TCP port number as another name/value claim to that credential set. And having to port-scan the entire range of 1-65535 introduces a multiple-orders-of-magnitude delay for scanning attackers compared to always listening on port 22 (even with Port Knocking protection), and makes it easy to blocklist too.

@TheD A moral responsibility? I highly doubt it.

@TheD There is a saying: "The S in IoT stands for Security". The IoT boom convinces lots of companies which have little to no experience with networked computer systems to suddenly develop them for the mass market. When development teams which were used to developing firmware for closed shell systems (where security is a complete non-issue) suddenly need to create internet-connected software, then you get the results you would expect. Weak authentication, dilletantic or non-existent crypto, manufacturer backdoors, firmware which can either be patched by nobody or by anybody, etc..

@Philipp Exactly - why is why those companies need to step-up to their responsibility to the rest of the world to take proactive steps to implement security-in-depth - and if they don't then governments and legislatures around the world may very well hold them accountable for negligence.

@TheD Legislature for security will never be up-to-date. Germany tried, and they failed. They have a whole ministry of information security, and even their extensive guideline makes generous use of "state of the art" - because what is "state of the art" today is deprecated tomorrow.

@Alice My favourite way to think about security through obscurity, is that it does nothing to stop targeted attacks, but a lot to stop automated bot attacks. Therefore, as long as I'm not someone that is likely to be targeted, there's actually a lot of value in it.

@Philipp +1. My longstanding rule: companies with strong hardware engineering cultures really suck at software. And even software-driven companies can suck at security.

Disabling password auth is nice, but my (limited!) experience is that it's not necessarily essential. When I last analyzed login attempts from an open ssh port, the brute-force brigade didn't even manage to hit any legitimate usernames (other than root, which had login disabled). They did of course manage to DOS me by making so many connection attempts that the system became unresponsive, but that's a separate issue.

@FredStark Set up fail2ban, it will get rid of 99.99% of the attack traffic too.

@DmitryGrigoryev it will get rid of it after n attempts anyway! Yes, I use fail2ban on personal servers too. My personal risk profile is very low, so protecting from automated attacks is my main concern. I'm assuming that OP also has a low risk profile

@Architect and this answer tells you how long it would take for ONE attacker to discover your address. How many attackers do you think are scanning the IPv4 range for opened SSH ports? Then you know why it [and everyone else's] was discovered so fast.

@ThibaultD. That's true, but I am not that good with statistics. I'm sure someone who was could accurately explain how long it would take on average for a new potential target to be discovered.

@MechMK1 If it takes each attacker 90 minutes to scan the whole network, and you have 5400 attackers, then, on average, your host will be scanned once a second during these 90 minutes.

@Alexander Yes, but it's not a uniform distribution. You'd have an average with some sort of confidence interval. At least, that's what I remember from statistics class :D

@R..GitHubSTOPHELPINGICE 'Note that because of this, it's foolish to be allowing password authentication.' Even if the password is strong?

@gaazkam Strong passwords are good, but public keys are better

@ThibaultD. the problem isn't the distro vendors, it's Linux enthusiasts who take every opportunity to tell everyone how secure Linux is, when this is a property not of Linux but of competent configuration (something you can do with any platform). The distro vendors could address the problem but secure-by-default raises the bar to entry so they won't.