In this walkthrough, I set up a VS Code Dev Container, beginning with my use of Remote-SSH on homelab LXCs and my goal of running AI coding agents like Claude Code in an isolated, easily recreated environment. I cover writing a Dockerfile and devcontainer.json, how the extension automatically handles the VS Code server and workspace bind mounts, and the difference between UI and workspace extensions, including declaring them in the config for reproducible setups. I leave handling SSH keys for pushing code to a future post...
How to get a phone notification whenever someone SSHs into a VPS, using a PAM hook and the Ntfy push notification service. I explain why SSH access is a risk worth monitoring on otherwise locked-down servers, then walk through editing the sshd PAM config, creating a script that sends a curl request to an Ntfy topic on login, and restarting sshd to test it...
My freshly spun-up Ubuntu VPS starts receiving SSH brute-force login attempts against root within minutes, at roughly one attempt every 10 seconds. I cover disabling root SSH login by creating a sudo user, setting PermitRootLogin no in sshd_config, restarting sshd, and watching out for included config files in sshd_config.d that can override settings. I end with the idea of logging what passwords the bots actually try...
This is a follow-up to my earlier Ansible playbook post, covering how to handle different sudo passwords across servers. I show how per-host inventory variables work, explain why storing ssh passwords in plaintext is risky, and walk through moving credentials into an external vars file before encrypting it with Ansible Vault, including the create, edit, and ask-vault-pass commands...
Setting up SSH key-based login on a Synology NAS running DSM 7.1.1 takes a couple of extra steps compared to a standard Linux distro: enabling the SSH service and enabling user home directories, since DSM doesn’t create them by default and ssh-copy-id needs one. I walk through both settings in the DSM web interface, and note that most Synology tasks are usually easier and safer done through its web UI or Package Center...
I walk through moving a server from password-based SSH logins to key-based authentication as a defence against brute force attacks. I cover generating an SSH key pair on a Mac, installing the public key on the target machine with ssh-copy-id, and disabling password authentication on Ubuntu 22 by adding PasswordAuthentication no to a config file in sshd_config.d and reloading the ssh daemon. I also note console login still works if something goes wrong...
When a rebuilt or cloned virtual machine reuses the IP address of a previously connected host, SSH rejects the connection with a “remote host identification has changed” warning. I explain why SSH behaves this way and show how to remove the stale entry from the known_hosts file using ssh-keygen -R so the host can be connected to again...
I take a look at why leaving SSH password authentication enabled is risky, and why key-based auth with passwords disabled is a sensible setup for any internet-facing server. While reviewing server logs, I noticed sshd timeouts and suspicious kex_exchange_identification messages, and traced the IP address to a host in China flagged by others for brute force attacks...
