diff --git a/src/routes/blog/2026/0214.md b/src/routes/blog/2026/0214.md new file mode 100644 index 0000000..86f6782 --- /dev/null +++ b/src/routes/blog/2026/0214.md @@ -0,0 +1,30 @@ + + +Earlier today, I went through `journalctl` on my server to view some copyparty logs when I discovered that the `ssh` logs were *swamped* with login attempts. Day and night, no more than a few seconds apart from one another, thousands of login attempts from random IP addresses trying to log onto my server with any kind of username they could think of: `root`, `admin`, `mysql`, `denizk0461`, `gmodserver`, `git`, etc. + +I thought I was safe from this; after all, I quite vividly remember talking to my former boss about my server and having him tell me how **incredibly unsafe** it is to use password-based authentication, and telling him reassuredly that I set up my server so that I would log in using an `ssh` key and a password. I also remember when I set up my server through Hetzner's website, I specifically said I'd use it via `ssh` and they didn't mail the `root` user password to me because of this. + +All of this was and still is true. But then I remembered: when I set up `ssh` on my Raspberry Pi recently, I followed a guide that said you had to manually disable password-based authentication in a config file. And I don't remember doing that on my public-facing server... + + + +So I checked the config file at `/etc/ssh/sshd_config` and found the line `#PasswordAuthentication no`. It was commented out, as it is by default! This means that anyone could try to brute-force my account passwords on my server! And I never noticed because I never needed the password; I'm logging in via `ssh` keys, after all. Only after trying to connect to the IP without the key did I find out that this was actually possible all this time. + +So I uncommented the line, reloaded the service via `sudo systemctl reload ssh`, verified that my key-based login was still working, then tried the password-based login and was greeted with the message *"Permission denied (publickey)."* + + + +Satisfyingly, all the login attempts documented in `journalctl` are now suffixed with *"[preauth]"*, meaning the people can't even get to the login prompt anymore because they're missing my private keys. I know I'm not 100% safe... but it feels a lot safer now than it did before. + +It's worrying to think about what damage one of them may have been able to do if they had gotten in. Especially since some were apparently looking for files containing sensitive data that were left in the open; one was really eager to find `.env` files, likely to try and discover some kind of password or other secret. + +Lesson learned: if you have some kind of publicly-facing server, check that unwanted people are restricted from even attempting to log onto it. If you're only *kind of* sure, check! \ No newline at end of file diff --git a/src/routes/blog/posts.ts b/src/routes/blog/posts.ts index a52048b..da091e5 100644 --- a/src/routes/blog/posts.ts +++ b/src/routes/blog/posts.ts @@ -30,6 +30,17 @@ export const posts: BlogPostLink[] = [ // title: "Portsmouth Postmortem", // description: "", // }], + { + key: "2026/0214", + post: { + date: "2026-02-14", + time: "19:46", + banner: "logins.webp", + bannerAlt: "A curved stick from a tree with some dry leaves attached. Its form resembles an entity with two legs, a spine, and no arms, leaning over and looking sad.", + title: "SSH Woes", + description: "About how I was shocked to learn that my server was open for attacks for well over a year.", + } + }, { key: "2026/0208", post: { diff --git a/static/blog/2026/0214/404.webp b/static/blog/2026/0214/404.webp new file mode 100644 index 0000000..e158c0c Binary files /dev/null and b/static/blog/2026/0214/404.webp differ diff --git a/static/blog/2026/0214/logins.webp b/static/blog/2026/0214/logins.webp new file mode 100644 index 0000000..571fa5b Binary files /dev/null and b/static/blog/2026/0214/logins.webp differ