Coder Legion - Recent posts tagged ssh

Build a small reusable Linux checklist in FastRemote

Sun, 20 Sep 2026 10:17:22 +0000

Disclosure: This tutorial is provided by the FastRemote product team and introduces our product. It was generated by an AI agent at our request, using documentation for released 1.1.5 functionality. Examples are for authorized test environments. FastRemote is a commercial SSH/SFTP desktop app for Windows, macOS, and Linux. Its 15-day trial must be started explicitly and does not require a payment method.

A command library is most useful when it contains commands you understand. Start with four checks you repeat, rather than importing a large collection and hoping every command suits your server.

This exercise uses a Linux test host. The commands inspect state and do not need elevated privileges.

Choose four tasks

Create a group in FastRemote's command library for basic Linux checks and add separate entries:

Entry name	Command
Current user	whoami
Hostname	hostname
Working directory	pwd
Filesystem space	df -h

Use the task as the entry name. Add a short note describing what the output means. Do not store passwords or API keys in command text or notes.

Test each command yourself

Connect to your test server. Check the selected SSH target and run each command once in the terminal.

This establishes both what the command does and whether it is suitable for that operating system. A Linux command should not be assumed to behave the same way in Windows PowerShell.

If you manage several systems, use separate groups and clear names.

Paste before executing

When taking a command from FastRemote's command library, beginners should start with the paste-only action. Read the text and check the target, then press Enter.

This is particularly helpful once commands contain variables, paths with spaces, or multiple lines. A saved command is still code that will run with your remote account's permissions.

The direct execution action can save an interaction once you are comfortable with an entry and its context.

Connect output to a decision

A disk-space check should tell you which filesystem deserves investigation. It should not automatically trigger a deletion command.

An unexpected username should send you back to the connection settings rather than immediately to a privilege-escalation command.

Keep the library maintainable

For each later addition, record its purpose, supported system, and whether it changes data. Review exported command files for sensitive values before sharing them.

You are finished when you can retrieve a familiar check without hunting through browser tabs, understand its output, and run it on the intended machine. FastRemote supplies the organization and reuse; your notes preserve the reasoning behind each entry.

Product information and downloads: FastRemote website.

My Servers Get Scanned Every 40 Seconds. Here's How I Stopped Caring — And Fixed It Anyway

Fri, 11 Sep 2026 17:01:14 +0000

I'm exhausted. Genuinely, professionally exhausted. Every server I stand up, no matter how boring, no matter how "it's just a staging box, nobody even knows the IP" — gets scanned before the SSL cert finishes provisioning. I used to take it personally. I used to open /var/log/auth.log, see four hundred failed logins from some IP block in a country I've never shipped a package to, and think: why me specifically?

It's not you specifically. That's actually the first thing you need to internalize before any of the technical advice below will make sense to you emotionally instead of just intellectually. Internet-wide scanning is background radiation now. GreyNoise's Global Observation Grid clocked roughly 212 exploitation attempts per second across the back half of 2025, from nearly 3 billion malicious sessions and 3.8 million unique source IPs hitting internet-facing infrastructure. You are not being hunted. You are being sampled, by the same dumb scripts that are sampling literally everyone else with a public IP, including your neighbor's smart fridge.

Once that sinks in, the panic turns into engineering, which is a much more useful emotional state. So let's do the engineering.

Myth #1: Changing the SSH Port Is "Security"

No. It isn't. I need you to hear this from someone who has changed the SSH port on every server they've ever owned: it is not security, it is noise reduction. A full port scan finds your "hidden" SSH port in about four seconds, and any attacker who is actually targeting you specifically — as opposed to sweeping the entire IPv4 space with a botnet — will find it just as fast.

What it does do, and this is legitimately worth doing, is cut out the overwhelming majority of low-effort automated scanners that only ever probe port 22 because probing every port on every IP is expensive even for a botnet. Cleaner logs. Less fail2ban noise. Fewer 3 AM "wait, is this real" moments. Do it, but do it with your eyes open: you're sweeping the porch, not installing a deadbolt.

The Actual Deadbolt: SSH Hardening That Isn't Theater

Here's the sshd config that actually matters, and I want you to notice something about it: none of it is exotic. It's the boring stuff nobody does because it involves editing a file instead of installing a shiny dashboard.

# /etc/ssh/sshd_config.d/99-hardening.conf

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
PermitEmptyPasswords no
MaxAuthTries 3
MaxSessions 4
LoginGraceTime 20

AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no
PermitTunnel no

AllowUsers your_actual_username

ClientAliveInterval 300
ClientAliveCountMax 2

Generate an Ed25519 key if you're still rocking RSA-4096 out of nostalgia — it's smaller, it's faster, and the public key is about 68 characters instead of 800-plus:

ssh-keygen -t ed25519 -C "you@host"

Test your new config in a second terminal before you reload sshd. I'm not going to explain why. If you've never locked yourself out of a box at 2 AM over a typo in sshd_config, you will, and that day will teach you faster than I ever could. Just do the test-in-a-second-terminal thing now and skip the lesson.

sudo sshd -t && sudo systemctl reload sshd

Password authentication being off is the single highest-leverage change on this entire list. GreyNoise's edge report noted a credential-spraying botnet targeting exposed RDP that grew from 2,000 to 300,000 participating IPs in 72 days — a 150x jump in about two and a half months, with the majority of it riding on compromised residential connections. That's the fate of anything on the internet still accepting admin / Password123! in 2026. Don't be the box that's still allowing it out of laziness.

Default-Deny Firewall, Because "Allow Everything, Block What I Notice" Isn't a Strategy

Whatever you use — nftables, ufw, firewalld — the policy should be deny by default, allow the minimum set of ports you actually serve. Not "allow everything and block IPs after they annoy me." Deny-by-default means the scanners hitting the other 65,530 ports just get silently dropped, which also, pleasantly, makes your box slightly harder to fingerprint.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw limit 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

That limit instead of allow on SSH isn't a typo — ufw's rate-limiting will auto-block an IP that hits the port more than six times in thirty seconds. It's a free, built-in speed bump before fail2ban even wakes up.

Fail2ban vs CrowdSec: Pick a Fighter

This is where I watch people either overthink it or underthink it, so let's settle it cleanly.

Fail2ban watches your logs, notices repeated failures, and bans the offending IP at the firewall. It's been quietly doing this job for over a decade, it has zero external dependencies, it phones home to nobody, and on a 512MB box it barely registers. If you're running one server with SSH and maybe a web app, fail2ban is completely sufficient and there's a real argument for not overengineering past it.

# /etc/fail2ban/jail.local
[sshd]
enabled = true
maxretry = 3
bantime = 1h
findtime = 10m
ignoreip = your.own.ip.address

That last line matters more than any other line in this entire article. Add your own IP to ignoreip before you enable anything. Locking yourself out of your own server over your own typo is a rite of passage nobody actually enjoys.

CrowdSec does the same local detection but adds a crowdsourced reputation layer: your agent optionally shares anonymized attack signals and receives a community blocklist in return, so an IP that hammered someone else's Ghost blog in Estonia last week gets pre-emptively blocked on your box before it ever sends you a single packet. It splits detection from enforcement — an engine that decides, and separate "bouncers" that actually carry out the ban at the firewall, at your reverse proxy, or in front of multiple servers from one shared decision list.

If you're running a single personal box, fail2ban is fine — go ahead, sleep well. If you're running anything public-facing at scale, multiple servers, or you're just tired of every server relearning the same lessons independently, CrowdSec's shared blocklist and centralized decision-making genuinely earns its extra moving parts.

Patch the Old Stuff. No, Really, the Old Stuff

Here's the part that should offend your sense of narrative logic: GreyNoise's 2026 State of the Edge report found that pre-2015 CVEs generated roughly four times more exploitation traffic than CVEs disclosed in 2023–2024. Shellshock. Old PHP-CGI bugs. Ancient WebLogic flaws. Vulnerabilities old enough to vote are still out there generating millions of exploitation attempts, because there are still millions of boxes nobody ever patched, and scanning for a decade-old known-good exploit is cheaper and more reliable for an attacker than gambling on something novel.

Your bot army isn't targeting you with next-generation zero-days. It's targeting you with the software equivalent of trying every car door in the parking lot, because somewhere, someone genuinely still left it unlocked. Run unattended-upgrades, set a reboot window, and stop assuming "it's old, nobody cares about it anymore" is a security posture. It is, statistically, the opposite of one.

The IP-Reputation Illusion Is Over

If your entire defense strategy is "block IPs that look sketchy," I have bad news. GreyNoise's residential-proxy research, based on 4 billion malicious sessions over 90 days, found that nearly 4 in 10 attacking IPs are residential — ordinary home broadband, mobile data, small-business routers, quietly compromised and rented out as attack infrastructure. One residential proxy network Google's Threat Intelligence Group took down in January 2026 was running 9 to 11 million daily active proxies used by over 550 distinct threat groups, including state-sponsored ones. Your grandmother's router might, statistically, be more dangerous than she is.

The takeaway isn't "give up on IP blocking." It's "don't let IP blocking be your only layer," because the entire premise that you can infer intent from an IP address is, as GreyNoise's own CEO put it, broken at scale. Behavior-based detection (what CrowdSec's scenario engine does, what a WAF does) matters more now than reputation lists alone.

Troll Them Back: Tarpits Are Underrated and Extremely Funny

This is my favorite category, because most security advice is defensive and boring, and tarpits let you be defensive and petty, which is a combination I fully endorse.

Endlessh is an SSH tarpit: point it at port 22 (move your real sshd elsewhere), and it exploits a genuinely funny loophole in the SSH RFC — the server is allowed to send junk banner lines before the real version string, with no upper limit on how long it can stall. Endlessh sends an infinite trickle of random banner bytes, a few bytes every few seconds, and just… holds the connection open. Forever. Automated SSH brute-forcers, which are almost always single-threaded per target and not built to handle a server that never actually says hello, just sit there, burning a thread, going nowhere, for as long as you let them.

docker run -d -p 22:2222 -p 127.0.0.1:2222:2222 --name endlessh figiel/endlessh

Nepenthes and its cousin Iocaine do the same thing for web crawlers instead of SSH bots: an infinite maze of auto-generated fake pages, all linking back into themselves, all stuffed with Markov-chain gibberish that's just structured enough to look like content. Point a misbehaving scraper at it and it doesn't get an error, it doesn't get a block page — it gets an infinite hallway with no exit, and it keeps walking because nothing in its logic tells it to stop. It's less "you shall not pass" and more "you shall pass, forever, into nothing." Deploy it behind a Disallow in robots.txt and let anything that ignores that directive enjoy the consequences.

Neither of these replaces real hardening. Think of them as the security equivalent of leaving out a bowl of pennies for door-to-door scammers — it wastes nobody's time who matters, and it wastes a genuinely satisfying amount of time for everyone else.

Least Exposure: Turn Off What You're Not Using

Every listening service is an entry point you now have to defend, patch, and think about at 3 AM. Run ss -tulpn, look at every single line, and ask yourself honestly whether you meant to expose it.

ss -tulpn

Uninstall what you don't need. Remove build tools and compilers from production hosts — if an attacker does get a foothold, you'd rather they didn't have gcc sitting there ready to compile their next stage for them. This is unglamorous work and it will not show up in a conference talk, but it closes more real doors than any single clever tool on this list.

The Layered Reality Check

None of the above is a silver bullet, and if anyone tries to sell you one tool as "solves scanning forever," check their LinkedIn for how many "growth hacker" job titles they've had. Scanners aren't going away. GreyNoise isn't reporting billions of sessions because attackers are winning some grand campaign against you personally — they're reporting it because sweeping the entire internet costs them almost nothing and occasionally, somewhere, it works. Your job isn't to make yourself unscannable. It's to make yourself boring: patched, key-only, minimally exposed, quietly logged, and — if you're feeling generous — wasting a few bot-hours a day in a tarpit out of pure spite.

Stack the boring layers. Skip the panic. Let the bots enjoy the maze.

Keeping a Web-Backed SSH Terminal Alive Across SwiftUI Navigation

Sun, 09 Aug 2026 04:53:28 +0000

A desktop SSH client can keep the remote connection alive and still give the user the impression that the terminal was reset. The failure often sits one layer above SSH: the UI destroys and rebuilds the terminal surface when the user switches to another section.

That distinction matters when a macOS app embeds xterm.js in WKWebView. The SSH process, terminal model, WebKit process, DOM, scrollback, focus chain, and visible geometry all have different lifetimes. Treating them as one SwiftUI view makes normal navigation surprisingly destructive.

This article describes the design rules we ended up using in a native macOS SSH client.

Why rebuilding is not a harmless refresh

A straightforward SwiftUI implementation conditionally creates the selected section:

if selectedSection == .terminal {
    TerminalSurface()
} else {
    FilesView()
}

When the condition changes, SwiftUI is free to dismantle the terminal subtree. If that subtree owns a WKWebView, the app can lose much more than a view object:

the WebContent process and xterm.js DOM may be destroyed;
scrollback stored only in the browser process disappears;
alternate-screen applications such as vim, nano, or top cannot be reconstructed from plain text;
restoring a bounded output snapshot may omit older history;
WebKit initialization and snapshot replay add visible latency;
focus and resize events can arrive in a different order after reconstruction.

Keeping the SSH handle alive does not solve any of these UI-state losses. The remote PTY may still be healthy while the local terminal surface has forgotten how to represent it.

Separate four lifetimes

The useful mental model is to separate at least four things:

Logical session: the tab, server identity, name, working directory, and user-facing state.
Transport session: the SSH handle and remote PTY that carry input and output.
Terminal renderer: the WKWebView, xterm.js DOM, parser state, and scrollback.
Visible attachment: whether that renderer currently participates in the AppKit view hierarchy and responder chain.

Navigation should normally change only the fourth lifetime. Closing a tab can end all four. A network failure may replace the transport while retaining the logical tab and renderer. Conflating those transitions is where most of the surprising behavior begins.

Mount once, then deactivate

After the terminal section is opened for the first time, keep its SwiftUI subtree mounted. Other sections can still be created normally, while the terminal surface changes visibility and interaction state:

if terminalHasLoaded || selectedSection == .terminal {
    TerminalSurface(isActive: selectedSection == .terminal)
        .opacity(selectedSection == .terminal ? 1 : 0)
        .allowsHitTesting(selectedSection == .terminal)
}

This preserves the representable and its coordinator instead of asking SwiftUI to rebuild them on every sidebar click. The isActive value also gives terminal-specific shortcuts, toolbars, and event monitors an explicit lifecycle. Hidden terminal controls should not continue handling keyboard shortcuts while the user is working in Files or Settings.

Opacity alone, however, is not sufficient for a WebKit-backed terminal.

Preserve the WKWebView object, not necessarily its attachment

On macOS, an embedded WKWebView participates in AppKit focus, drag registration, and window behavior. Keeping it attached but transparent can leave side effects in sections that should have nothing to do with the terminal.

A more reliable arrangement is:

let NSViewRepresentable return a lightweight container;
let its coordinator hold a strong reference to the WKWebView;
attach the web view to the container only while the terminal section is active;
remove it from the hierarchy while inactive, without releasing the object;
attach the same object again when the user returns.

The WebKit object, WebContent process, xterm.js DOM, parser state, and scrollback stay alive even while the view is temporarily detached. The rest of the app no longer has an invisible WebKit view interfering with hit testing or drag sessions.

This is different from serializing terminal text and creating a new renderer. It preserves the renderer itself.

Hand focus back before detaching

Focus is a correctness issue for terminals, not just polish. If the window's first responder remains inside the web view during a section switch, later keystrokes can be delivered somewhere the user cannot see. In the worst case, a stray character is interpreted by the remote shell.

Before detaching an active terminal web view:

Check whether the window's first responder is the web view or one of its descendants.
Explicitly clear or move the first responder.
Remove the web view from its container.
Disable terminal-only keyboard monitors and shortcut controls.

When reattaching, restore focus deliberately after the container is visible. Avoid assuming that SwiftUI's appearance callback and AppKit's responder-chain update happen in the same frame.

Freeze hidden geometry

A hidden but mounted view can still receive geometry changes. If its width follows every animation in the visible section, xterm.js may repeatedly run fit(), and each result may resize the remote PTY.

That creates a subtle class of bugs: opening a file-transfer panel or animating another page changes the dimensions of a terminal the user is not looking at. Full-screen terminal programs then redraw against "ghost" sizes.

Record the terminal's last active width and freeze the inactive container at that width. On reattachment:

align the web view to the visible container once;
let the renderer's resize observer compute the new rows and columns;
send one meaningful PTY resize instead of a frame-by-frame storm.

The same rule applies to side panels: reserve their width only in the section that owns them, not at a shared ancestor that also sizes the hidden terminal.

Keep output flowing without flooding the UI

Detaching the renderer should not pause the SSH transport. Output can continue updating the logical session and renderer while the user visits another section.

High-volume PTY output needs its own boundary. Read callbacks can arrive hundreds of times per second, while sending every chunk through the main thread and WebKit IPC creates unnecessary contention. A practical policy is:

deliver sparse output immediately so typing echo feels instant;
merge continuous bursts into roughly one flush per display frame;
update the bounded recovery buffer before notifying the renderer;
keep session logs on a separate path from visual replay.

The recovery buffer remains useful if WebKit really crashes, but it is no longer the normal navigation mechanism.

Test transitions, not just steady states

The most valuable tests are sequences:

start top, switch to Files, resize the window, and return;
scroll far back, visit Settings, and confirm the same scrollback remains;
focus the terminal, switch sections, type immediately, and verify nothing reaches SSH;
open and close a side panel while the terminal is hidden;
disconnect while hidden, then return and exercise the reconnect path;
close a terminal tab while its web view is detached and confirm observers and script handlers are removed.

These tests cross SwiftUI, AppKit, WebKit, and SSH boundaries. A unit test around one layer will not reveal the ordering failures between them.

The broader rule

View visibility and resource lifetime are not the same thing. A terminal is a long-lived interactive resource with a UI surface, not a disposable page. Once the logical session, transport, renderer, and visible attachment have separate ownership, navigation becomes predictable: switching sections changes what the user sees without quietly rebuilding the tool they were using.

Developer disclosure: I work on Nexus Shell, a native macOS SSH workspace. This article is based on implementation and debugging lessons from that work, not a benchmark against other clients.

Editorial note: This draft was prepared with AI assistance and reviewed against the current SwiftUI, AppKit, WebKit, and SSH implementation before publication.

Now That You've Purchased Your VPS, Let's Make It More Secure...

Thu, 02 Jul 2026 03:18:27 +0000

Introduction

Having purchased our VPS, we're well on our way to setup Coolify. I'm getting excited and I hope you're excited about that, but before we actually get to that installation there is another step we must take. We must secure our VPS. My Linux OS is Ubuntu.

In this post we're going to look at 4 easy steps we can take to make our VPS a harder target to hit. There, will be other measures we can take in the future but these will get us prepped, to start setting up Coolify. The four basic steps we will look at are:

* Create Sudo User/ Disable Root Login
* Enable UFW Firewall
* Change the default SSH Port Number
* Install Fail2Ban

Let's get Started.

The Root Username is Public Knowledge : Every single Linux server in the world has an account named root. Because hackers already know this username, they only have to guess your password or exploit one single vulnerability to take total control of your server. Creating a custom username forces hackers to guess both a unique username and a password, which is significantly harder to break.

Guardrails Against Accidental Destruction : The root user operates without any safety nets. If you run a destructive command by accident while logged in as root, the server will execute it instantly without asking questions.

Example: Running rm -rf / as root will delete your entire operating system instantly. A normal user requires you to type sudo before administrative tasks. This extra step acts as a warning prompt, forcing you to type your password and think twice before executing dangerous commands.

Protection Against Automated Bots : The moment your VPS goes online, malicious automated bots will start scanning its IP address. These bots constantly bombard the root user with thousands of automated password guesses per minute (known as a brute-force attack). By disabling root login entirely, you immediately render all of those automated attacks completely useless.

Better Accountability and Logs : If multiple people ever need access to your server, sharing the root account makes it impossible to know who did what. When everyone uses their own unique standard account and uses sudo for admin tasks, Ubuntu keeps a clean history log /var/log/auth.log). This log shows exactly which specific user executed which command, giving you a clear audit trail.

Commands

Creating a Sudo (Superuser Do) User

Create the new user
your-command-prompt:~$ adduser your_user_name_goes_here

Add the user to the sudo group
your-command-prompt:~$ usermod -aG sudo your_user_name_goes_here

Note : Log out of the root user and log in with the sudo user then disable the root account

Lock the Root Password (optional)
your-command-prompt:~$ sudo passwd -l root

Verify Root Account is locked
your-command-prompt:~$ sudo passwd -S root

Note : Your output will look like this - root L 05/12/2026 0 99999 7 -1 or this - root LK 2026-05-12 0 99999 7 -1

Disable Root Login via sshd_config file
your-command-prompt:~$ sudo nano /etc/ssh/sshd_config

In your sshd_config file look for the line that says PermitRootLogin yes. Its most likely at the bottom of the file. Change yes to no, then press ctrl O to apply the change, then press enter to confirm, ctrl X to exit.

Restart the sshd Daemon
your-command-prompt:~$ sudo systemctl restart sshd

Note: a and G are what you call flags in a linux operating system. Flags are used to modify the behaviour of a command.
-G: The uppercase -G stands for Groups. This flag tells the system that you want to add the user to the group name that follows it (in this case, the sudo group).
-a: If you use -G by itself (without the -a), it will overwrite your user's existing groups. The system will remove the user from every other group they belong to, leaving them only in the new group you specified. Instead of wiping out your user's existing groups and replacing them, it tells the system to simply add (append) the new group to the user's current list.
-aG: By combining them into -aG, you are telling Ubuntu: "Add this user to the sudo group, but keep all of their existing group memberships exactly as they are."

Test your new User
your-command-prompt:~$ groups your_user_name_goes_here

The UFW (Uncomplicated Firewall) Firewall

Blocks Brute-Force Attacks : Automations constantly guess passwords on exposed ports; a firewall shuts down unneeded entry points.

Restricts Open Ports : Database engines (like MySQL) or internal tools stay hidden from the public internet.

Limits Protocol Access : You can restrict sensitive services like SSH to only accept connections from your specific home or office IP address.

Mitigates Malicious Traffic : It helps drop unexpected incoming traffic, reducing the impact of basic denial-of-service attempts.

Prevents Exploitation : If an application you run has a hidden security flaw, a firewall can stop hackers from connecting to it.

Commands

Allow SSH connections so you don't lock yourself out
your-command-prompt:~$ sudo ufw allow OpenSSH or sudo ufw allow 22/tcp

Allow web traffic if you plan to host a website
your-command-prompt:~$ sudo ufw allow http or sudo ufw allow 80/tcp
your-command-prompt:~$ sudo ufw allow https or sudo ufw allow 443/tcp

Enable the Firewall
your-command-prompt:~$ sudo ufw enable

Check the Firewall Status
your-command-prompt:~$ sudo ufw status verbose

Change the default SSH port from 22 to something obscure

The reality is that the moment a VPS gets a public IP, automated bots start hammering port 22 within minutes. They're not targeted attacks — just scripts scanning the entire internet looking for default SSH ports to brute-force. Moving to port 54322 (or any non-standard port) makes you invisible to those dumb scanners.

The security community calls this, security through obscurity and generally considers it a weak standalone measure. But combined with the real hardening (SSH keys, no password auth, Fail2ban) it's a cheap quality-of-life improvement that keeps your logs clean.
The honest framing: it's not on the list because it makes you safer — it's on the list because it stops your logs from being flooded with bot noise, which makes it easier to spot actual suspicious activity.

Commands

Change the Port on the Server
your-command-prompt:~$ sudo nano /etc/ssh/sshd_config

In your sshd_config file look for the line that says #Port 22. Delete the hash and change the number to the port you want, then press ctrl O to apply the change, then press enter to confirm, ctrl X to exit.

Add your new SSH Port Number
your-command-prompt:~$ ufw allow 54322/tcp
your-command-prompt:~$ sudo ufw reload
your-command-prompt:~$ sudo systemctl restart sshd

Protect your Ubuntu server from automated brute-force password guesses: Fail2Ban

What is Fail2Ban

Fail2ban is a tool that scans log files for suspicious activity, like excessive failed login attempts, and blocks potentially harmful IP addresses. This free service protects Linux systems from brute force attacks by temporarily rejecting IPs exhibiting suspicious behavior, thereby reducing the risk of unauthorized access.

Why Consider Fail2Ban

Easy Setup & Free : Fail2ban is easy to install and configure, requiring minimal expertise. As a free, open-source tool, it provides an accessible and cost-effective way to enhance server security without added software costs.

Customizable Configuration : he tool provides extensive customization options. You can tailor it to monitor specific services, set the ban duration, or even whitelist trusted IPs, allowing you to adapt it to your unique security needs.

Brute Force Protection : It’s particularly effective at preventing brute force attacks by automatically banning IP addresses that show malicious behavior, such as repeated login failures.

Efficient Resource Usage : Fail2ban bans attackers at the firewall level, which helps reduce the load on your server by preventing malicious traffic from consuming resources.

Alerts and Notifications : Integration with notification services means you can get real-time alerts when suspicious activity is detected, helping you stay informed and responsive.

Limitations of Fail2Ban

Reactive Nature : It only blocks an IP after the attacker has already made a set number of failed attempts. It does not prevent the initial probe.

False Positives : Legitimate users can be temporarily locked out if they mistype a password a few times in quick succession.

Ineffective Against Distributed Attacks (DDoS) : Because it operates on IP addresses, it is easily bypassed by botnets that rotate through thousands of different IPs, making it a poor tool for stopping distributed traffic floods.

IP Spoofing : Attackers can spoof IP addresses, potentially tricking Fail2Ban into blocking innocent third-party IPs.

Docker Conflicts : When run on a Docker host, Fail2Ban's default iptables rules frequently conflict with Docker's internal networking, causing bans to fail entirely or impact the wrong containers

There is a work around for the Docker Conflicts but I just thought I should mention it so you would be aware.

Commands

Update your Package List
your-command-prompt:~$ sudo apt update

Install Fail2Ban
your-command-prompt:~$ sudo apt install fail2ban -y

Note : Why the -y flag? It tells the package manager to automatically answer "yes" to all prompts and confirmations during the installation process, allowing the command to run completely unattended.
Warning!!! Only use the -y flag when you are 100% sure about the package you are installing.

Start and Enable the Service to Run on Boot
your-command-prompt:~$ sudo systemctl start fail2ban
your-command-prompt:~$ sudo systemctl enable fail2ban

Conclusion

That's it for now. There is always more that can be done but we have started with the basics. What is most important is not just implementing security measures but that we must have an attitude that defaults to a secure development environment.

Many security breaches starts in the mind, because we do things with out considering the consequences. This has got to stop. We can even translate this into how we live, where we go and what we do.

Always look for ways to make you VPS more secure and still allow it to perform efficiently.

Keep up the good Work!

How to Expose Localhost to the Public Using Nginx and SSH Tunnels

Sun, 03 May 2026 09:35:44 +0000

Hello, I'm Ganesh. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on Github. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product.

As a developer, you’ve likely faced this hurdle: You are building a complex application on your local machine, and you need to show it to a client or test a webhook of your application.

You could deploy it to a staging server, but that's slow.
You could use Ngrok, but the free tier has limits and dynamic URLs.

Today, I’ll show you how to build your own "Unlimited" Reverse Proxy using Nginx, Autossh, and a small VPS.

The Architecture

The goal is to route traffic from a professional URL (like test1.yourdomain.com) directly to a port on your local machine (like localhost:3000).

We use three layers of technology to make this happen:

Nginx: Acts as the entry point and handles SSL (HTTPS).
SSH Reverse Tunnel: Creates a secure "pipe" from your VPS back to your laptop.
Autossh: Ensures that if your internet flickers, the "pipe" automatically reconnects.

Step 1: The Remote Server (Nginx)

On your server, you need an Nginx configuration that listens for HTTPS traffic and passes it to a local port.

server {
    listen 443 ssl http2;
    server_name test1.yourdomain.com;

    ssl_certificate /etc/letsencrypt/live/your-domain/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/your-domain/privkey.pem;

    location / {
        # Proxy traffic to the SSH-forwarded port
        proxy_pass http://127.0.0.1:6540;

        # Keep the original user's info
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }
}

Step 2: The Local Bridge

On your local machine, you need to open the tunnel.

Using a Makefile or a shell script makes this repeatable. The core command uses the -R flag, which stands for Remote Forward.

# -R [Remote Port]:[Local Destination]:[Local Port]
autossh -M 20000 -R 6540:localhost:3000 root@your-server -N

Why this is "Unlimited"

Unlike third-party services, this setup gives you:

Total Control: No timeout limits or bandwidth caps (other than your own ISP's speed).
Professionalism: You use your own domain and your own SSL certificates.
Security: Your local machine is not truly "exposed." Only the specific port you choose (8081) is bridged through the encrypted SSH tunnel.

Troubleshooting Common Gotchas

502 Bad Gateway: This usually means Nginx is working, but your SSH tunnel isn't running or is on the wrong port.
Port Already in Use: If you restart your tunnel quickly, the server might still think the old one is active. Use a cleanup script to kill -9 <PID> any process currently sitting on your remote port before starting a new one.
Firewalls: Ensure your VPS allows traffic on ports 80 and 443!

Conclusion

By combining the stability of Nginx with the flexibility of SSH tunneling, you've created a production-grade development environment.

You now have a permanent bridge between your local setup and the rest of the world.

Any feedback or contributors are welcome! It’s online, source-available, and ready for anyone to use.
⭐ Star it on GitHub: https://github.com/HexmosTech/git-lrc

How does SSH work and how can it be set up?

Wed, 29 Apr 2026 05:42:27 +0000

Secure Shell (SSH) is a cryptographic network protocol that allows you to operate network services securely over an unsecured network.

It is most commonly used for logging into a remote terminal and executing commands.

How SSH Works

SSH uses a client-server model and relies on a suite of encryption technologies to ensure that data remains confidential and untampered.

1. The Handshake

When we connect to a server, the two machines exchange supported encryption protocols and settle on a mutually compatible version.

They also establish a session key using a process like the Diffie-Hellman algorithm, which allows them to create a shared secret without actually sending the key across the network.

Here is the video explaining this process:
Link

2. Authentication

Once the encrypted channel is established, the server needs to verify who you are. This usually happens in one of two ways:

Password Authentication: You send your password through the encrypted tunnel.
Key-based Authentication: The most secure method, using a Public Key (stored on the server) and a Private Key (stored on your machine).

3. Encryption Layers

SSH utilizes three different types of encryption:

Symmetrical Encryption: Uses one key for both encryption and decryption of the entire session.
Asymmetrical Encryption: Uses a public/private key pair (used primarily during the handshake and for authentication).
Hashing: Uses algorithms (like HMAC) to ensure data integrity, proving that the packets haven't been altered during transit.

For let's setup simple RSA key pair for ubuntu server.

How to Setup SSH

Since we are using ubuntu server, we need to install the SSH server on the server.

Step 1: Install the SSH Server

Assuming you are in cloud console want to setup ssh on ubuntu.

On the server, run:

sudo apt update
sudo apt install openssh-server

To check if it’s running:

sudo systemctl status ssh

Step 2: Generate SSH Keys (Recommended)

On your local machine, generate a key pair. This is much safer than using a password.

ssh-keygen -m PEM -t rsa -b 4096 -f ~/.ssh/private_key

Press Enter to save it in the default location.

You can add a passphrase for extra security.

gk@jarvis:~$ ssh-keygen -m PEM -t rsa -b 4096 -f ~/.ssh/private_key
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/gk/.ssh/private_key
Your public key has been saved in /home/gk/.ssh/private_key.pub
The key fingerprint is:
SHA256:i3qqpQpyRkjDAdnbe++rN+ZCzak/4Ryzsn5vGJYEsVg gk@jarvis
The key's randomart image is:
+---[RSA 4096]----+
|o+    E.         |
|o o  o..         |
| + o. ..         |
|..o .   .        |
|. .  . +So       |
| .  . o.@.       |
|o o .o.*.B       |
|oo o .= % .      |
|..o.o++%=*.      |
+----[SHA256]-----+

In the above output, we have generated a private key and public key.

we can copy public key and save it in server

Step 3: Copy the Key to the Server

Copy public key from local machine.

cat ~/.ssh/private_key.pub

Once you are inside server either in temperary console or using password.

Change directory to .ssh

Add public key to authorized_keys file.

This way server will trust your public key and you can login without a password.

Step 4: Connect

Now you can log in without a password:

ssh username@remote_host_ip

Conclusion

We understood how ssh works and how to setup ssh on server.

I hope this article helps you to understand ssh and how to setup ssh on server.

Any feedback or contributors are welcome! It’s online, source-available, and ready for anyone to use.
⭐ Star it on GitHub: https://github.com/HexmosTech/git-lrc

Simple backups using Rsync with SSH

Thu, 12 Feb 2026 13:35:25 +0000

This post explains how to SSH with Rsync to make backup of your system efficiently and securely.

The only requisite to start here is an access to SSH somewhere.

Create your ssh keys

Here, i just create a keypair called “rsync”, ssh will create a private and a public key.

ssh-keygen -t ed25519 -o -a 100 -f ~/.ssh/rsync

After, just send the public key to the server with scp targeting your server.

 scp ~/.ssh/rsync.pub backup@SERVER

Create a backup script

Create a shell script named rsync-backup.sh with the following content:

#/usr/bin/env sh

set -o errexit

# All variables
SERVER="192.168.1.11"
BACKUP_FILE="/tmp/backup.filter"

# More efficient than playing with --include,--exclude
cat << EOF > "$BACKUP_FILE"
# Include patterns
+ /documents/***
+ /Downloads/***
+ /downloads/***
+ /images/***
+ /musics/***

# Exclude everything else
- /**
EOF

# And finally the rsync command
rsync -avP --delete -e "ssh -i $HOME/.ssh/rsync" \
    --bwlimit=400 \
    --filter="merge $BACKUP_FILE" \
    "$HOME/" "backup@${SERVER}:backups/"

The script here will backup your $HOME with only certain directory in the “include pattern list”. Just ensure the server address is correct.

I also limit the bandwidth because it break my wifi card (bad hardware…)

Execute the script

Just give permission and launch the script.

 chmod u+x rsync-backup.sh
./rsync-backup.sh

Conclusion

Using SSH with Rsync is an efficient and secure method for backing up your system. By generating SSH keys and creating a simple shell script, you can automate the backup process, ensuring that your important files are safely stored on a remote server.

Adjusting settings like bandwidth limitation can help optimize performance, especially on networks with limited resources. This approach not only provides a reliable backup solution but also enhances data security through encrypted connections.

The Quest Continues: Porting the Word Game With AsyncSSH

Sun, 04 May 2025 23:33:09 +0000

Last week, we reimplemented our 20-questions variant, and it received quite a bit of attention. So far we built a web experience, as well as a command line interface for the game. However, unlike the web version, the command line interface is strictly local. There’s no way to share the game with a fellow friend unless we walk them through the setup. Coincidentally, a former coworker recently told me about hosting applications over secure shell protocol in Golang. That makes me wonder, how easily can we replicate it in Python?

A cute illustration from Copilot on the topic.

The Spark of an idea

The secure shell protocol (SSH) is usually what we use to log into another machine for work. Yet, there are a lot of interesting applications hosted over SSH. I remember there was one that would play back a Star Wars movie in ASCII art upon connecting successfully. Late last year, my coworker told me about a coffee shop selling freshly brewed coffee over SSH. We both found that idea intriguing.

He suspected the application was made with wish, a Golang library. That prompted me to see if there is an equivalent for Python, but I only found Paramiko at the time. After a quick glance at the documentation, I decided it was too much work and moved on. It does seem like it is capable of achieving the goal — serving a CLI application over SSH, though.

Yes, the em-dash is intentional.

Photo by Vitaly Gariev on Unsplash

Keeping in touch as usual, and he would bring up the wish project from time-to-time. Then fast-forward to last week, after I was done with the reimplementation of our little word game, I stumbled upon another library called AsyncSSH. Like Paramiko, it can be used to create an SSH server as well. The relatively more extensive examples also seemed helpful.

After some exchanges with Gemini, I received a generated proof-of-concept code that looked workable. After completing and publishing the article on the game, I finally had time to properly explore the topic. Read on to join the ride together in building an interactive application served over SSH.

Finding the Right Tool: Paramiko vs AsyncSSH

Like we briefly mentioned previously, Paramiko and AsyncSSH are libraries we can use to build SSH Server applications (they are also excellent as SSH client libraries). Though the former garnered more stars on GitHub, the amount of information on how to build an SSH Server application is surprisingly sparse. From what I read, it also required quite extensive setup.

The discovery of AsyncSSH was completely unintentional. It was buried deep in the search result when I was looking for a cohesive tutorial on Paramiko. While the design of the documentation site looked as if it was built in Python 2.0 era, the extensive collection of examples is extremely helpful. I particularly liked the simplicity offered by AsyncSSH in comparison.

Photo by Agence Olloweb on Unsplash

Our goal for this week is a fairly simple application sporting a simple REPL-like experience. The key of this exercise is to learn, hence efficiency isn’t a deciding factor. Therefore, the simplicity and developer friendly documentation make the library a sensible choice for our project this week.

Two Paths and a Relearning

Photo by Ross Sneddon on Unsplash

The quick proof-of-concept code I came out with the help of Gemini, by referring to the documentation, consists of 3 components. Firstly, we have the actual SSH Server class, subclassing asyncssh.SSHServer.

import asyncssh

class MySSHServer(asyncssh.SSHServer):
    def begin_auth(self, username):
        logger.info("logging in user:%s", username)
        return False

    def session_requested(self):
        return MyREPLSession()

This class is where we define all the authentication rules. For the purpose of this article, we are skipping all of them to maintain simplicity. Thus, we are returning False in begin_auth to indicate no authentication is needed. Do refer to the documentation for information on the topic before publishing applications in production.

The MyREPLSession is a class inheriting asyncssh.SSHServerSession, which defines the actual application logic we intend to serve over the server. The skeleton is shown as below:

class MyREPLSession(asyncssh.SSHServerSession):
    _chan = None
    _buffer = ""

    def connection_made(self, chan: asyncssh.SSHLineEditorChannel) -> None:
        self._chan = chan

    def pty_requested(
        self,
        term_type: str,
        term_size: tuple[int, int, int, int],
        term_modes: dict[int, int],
    ) -> bool:
        logger.info("pty received")
        return True

    def shell_requested(self) -> bool:
        logger.info("shell received")
        return True

    def data_received(self, data: str, datatype: int | None) -> None:
        # TODO The actual application
        pass

    def eof_received(self):
        assert isinstance(self._chan, asyncssh.SSHLineEditorChannel)

        self._chan.exit(0)
        return False

    def signal_received(self, signal):
        assert isinstance(self._chan, asyncssh.SSHLineEditorChannel)

        self._chan.exit(0)

    def break_received(self, signal):
        assert isinstance(self._chan, asyncssh.SSHLineEditorChannel)

        self._chan.exit(0)

There are a couple of key methods we need to implement. The first is the connection_made, in our setup we are expecting a asyncssh.SSHLineEditorChannel object. All the input and output through SSH would be handled by the channel object, hence it is crucial to keep a reference of it. Methods ending with the _received suffix are event handlers, and in our toy project, we simply close the channel when no more input is sent (upon EOF or on terminate/kill signals).

We will discuss data_received event handler later.

Lastly, we need to tie everything together through asyncssh.create_server. As implied by the library name, the function returns a coroutine object, and hence we would need to properly set up through AsyncIO. Feel free to revisit our previous article on how to write an asynchronous program. But for this example, we are adapting the example shown in the documentation.

AsyncIO Task Management: A Hands-On Scheduler Project

import asyncio

async def main() -> None:
    try:
        # Ensure ssh-host key exists before running
        await asyncssh.create_server(
            MySSHServer,
            "0.0.0.0",
            8022,
            server_host_keys=["./ssh-host"],
            line_editor=True
        )
        print("SSH server listening on port 8022...")
    except Exception as exc:
        print(f"Error starting server: {exc}")

if __name__ == " __main__":
    loop = asyncio.new_event_loop()

    loop.run_until_complete(main())
    loop.run_forever()

We previously used asyncio.run to run the main coroutine, and set up a ShutdownHandler working with an exit event object to end a program. On the other hand, this approach was likely written before asyncio.run was introduced, with the manual management of event loop being the telling sign. The run_forever() here also eliminates the hack where people put an infinite loop after asyncssh.create_server.

Essentially, the code snippet creates the server, where the server behaviour is defined by the MySSHServer, and we set line_editor=True to be explicit (as we are expecting user interaction in our session). Remember to create an SSH key for the application.

$ ssh-keygen -q -N "" -t ed25519 -f ./ssh-host

As mentioned earlier, we are building a very simple REPL-like application. Just as a refresher, REPL stands for read-evaluate-print-loop, which aptly fits our case here. We read user input, get DSPy to process it with the LLM in background, print the generated response, rinse-and-repeat. The skeleton of the flow is shown as below:

def main() -> None:
    game_setup_and_welcome_speech()

    while True:
        match input("> "):
            case command if command == "quit":
                break
            case attempt:
                process_and_print_reply(attempt)

Now we can populate our data_received handler. This method is called whenever our user is sending input through the SSH session. Unfortunately, we cannot assume the data is always ending with a newline (user pressing enter). Sometimes, the handler may have accumulated a couple of questions and send them in one go. The function may also get called while the user hasn’t done typing. For this, we would have to handle both cases, as shown below:

class MyREPLSession(asyncssh.SSHServerSession):
    _buffer = ""

    def data_received(self, data: str, datatype: int | None) -> None:
        assert isinstance(self._chan, asyncssh.SSHLineEditorChannel)

        self._chan.write(f"Welcome to my SSH server, {username}!\n\n")
        self._buffer += data

        lines = self._buffer.split("\n")
        for line in lines[:-1]:
            match line:
                case command if command == "quit":
                    self._chan.exit(0)
                    break

                case attempt if attempt:
                    process_and_print_reply(attempt)

        self._buffer = lines[-1]

Remember we talked about handling user input and output through the SSHLineEditingChannel object we received in connection_made? Output of our application is done through its write() method, just like how we output to stdout (to be displayed on the terminal emulator) through print() usually.

Let’s test the application.

A seemingly stalled game session

While the application worked, the experience wasn’t ideal. My modest GPU took quite a bit of time to generate a response for every user input, and somehow the cursor stalled and wouldn’t move to another line whenever the user pressed enter. It somehow gave an impression of the application just died after every enter.

Photo by Josh Redd on Unsplash

I was ready to move on, and start preparing to write, until I came across another example that fits the use-case. Now we have a code that looked a lot like the original skeleton.

async def handle_client(process: asyncssh.SSHServerProcess) -> None:
    username = process.get_extra_info("username")
    process.stdout.write(f"Welcome to my SSH server, {username}!\n\n")

    game_setup_and_welcome_speech()

    while True:
        match await process.stdin.readline():
            case command if command == "quit":
                break

            case attempt:
                process_and_print_reply(attempt)

    process.exit(0)

Previously we returned output through the SSHLineEditingChannel object, here we are doing it through the SSHServerProcess object. On the other hand, instead of input(), we read it through the readline() method in the stdin (an SSHReader object) property.

Then, we need to remove the session_requested method from MySSHServer, and define the process_factory argument in asyncssh.create_server to point to our new coroutine.

await asyncssh.create_server(
    MySSHServer,
    "0.0.0.0",
    8022,
    server_host_keys=["./ssh-host"],
    line_editor=True,
    process_factory=handle_client,
)

Re-run the application again, and to my surprise, it worked almost exactly like the original CLI version. For our project, the second approach definitely worked better. Nonetheless, the first attempt was also crucial, as it gives an idea on how input is being sent in a SSH session.

The choice of naming the property holding a SSHReader object as stdin, and the fact it reads input through a method named readline piqued my curiosity. I knew we could reach sys.stdin to read content redirected from the previous command (via the pipe | operator), or file content via the < operator (in Unix-like environments). That said, I didn’t know reading user input interactively in a running application is done through stdin as well.

My first experience writing a production CLI application started with PHP (very strange, yes). That was my first time learning about the relationship between the operators and stdin, stdout, and stderr through my supervisor. The scripts didn’t really need to collect input interactively, and given the similarity of PHP and C, I couldn’t find a scanf equivalent so I assumed PHP doesn’t have such feature.

I was wrong.

Photo by Mr. Bochelly on Unsplash

After some exchanges with Gemini, I realized I could use readline() in PHP for the task. Which itself is similar to scanf and input in Python. Alternatively, I could also use fgets(STDIN) to do the job, just that I need to figure out a way to print a prompt prior to the input collection. On the other hand, if I redirect some content into a Python application, if I call input(), it would read the content in stdin, until it encounters a newline character. Essentially, it roughly equates

import sys

sys.stdin.readline().strip()

Back to the topic, the toy example skipped many other aspects besides the authentication work we mentioned earlier. Unfortunately, due to the sheer scope and complexity, it is almost impossible for the developer to cover all use cases in the examples. Fortunately, the API documentation is very well-written, and I assume it could be useful for people who know more about the protocol.

We are lucky to live in an era where a LLM chatbot like Gemini is readily available, to provide help in navigating the documentation. Besides that, it also serves as a valuable companion to help gathering complementary information, like how I relearned stdin. Even so, critical thinking is still crucial while evaluating the response to avoid falling victim to AI hallucination.

Bridging Game and Server

Photo by Phil Hearing on Unsplash

We finally assembled all the pieces together and ported the game to be served over SSH. The concrete implementation can be found at the GitHub repository for those who are interested. Both the CLI version and SSH version (the handle_client variant) are very similar, as shown below

async def handle_client(process: asyncssh.SSHServerProcess) -> None:
    username = process.get_extra_info("username")
    process.stdout.write(f"Welcome to my SSH server, {username}!\n\n") # vs print()

    game_setup_and_welcome_speech()
    while True:
        match await process.stdin.readline(): # vs input()
            case command if command == "quit":
                break
            case command if command == "end" and answer is not None:
                answer = None
            case attempt:
                process_and_print_reply(attempt)

    process.exit(0)

The major difference between the two, is the use of process.stdout.write() to replace print(), and process.stdin.readline() to replace input (though a new coroutine called prompt_input is written to compose a process.stdout.write() to display prompt text).

async def prompt_input(process: asyncssh.SSHServerProcess, prompt: str) -> str:
    process.stdout.write(prompt)
    return await process.stdin.readline()

The REPL-like experience makes the word game a very synchronous experience. A response is only generated upon user submission of input. Therefore the await is necessary while expecting user input is needed to ensure order. Other than that, the asynchronous nature of AsyncSSH does not affect the game’s logic much. As each game session is independent, each time a new user connects, the library will run handle_client separately for each of them.

Once the log message shows “SSH server is listening …” after executing ssh.py, it is ready to be connected to with the following command.

$ ssh -p 8022 localhost

Considering we didn’t define any authentication methods in MySSHServer (which is definitely a bad practice), it should display a welcome message and the game is started right away.

In this article, we explored two different strategies to host our little word game over SSH. The two approaches have their own pros and cons, but it does show how AsyncSSH makes the development experience quite intuitive. Even though I do not have much experience doing this in Golang with wish (the documentation situation is also quite bad there), I enjoy the time spent doing this with AsyncSSH.

The Game Goes Live

Photo by Alessandro Erbetta on Unsplash

The point of the exercise is mainly on learning and discovery. If our game were developed with a text-based UI through Textual, or even Typer, some extra work is needed to ensure I/O is redirected properly.

The experience of porting the library to SSH is a series of happy coincidences. It started with a spark from a discussion with my former coworker, and it led to a series of discoveries. This article is a culmination of the whole journey, sharing what I learned throughout. It turns out building an application to be served over SSH just needed a change in how I/O is done. Gemini also helped immensely throughout, deepening my understanding.

We went through the whole process by configuring a server by subclassing a asyncssh.SSHServer, exploring two different ways to serve applications through process_factory and inheriting asyncssh.SSHServerSession, then getting it running via asyncssh.create_server.

Hopefully this article sparks an interest and we see more interesting applications hosted over SSH.

This article was written with assistance from Gemini, a large language model by Google. Gemini provided editorial help, fixing language errors and checking for article flow. However, the code and voice are entirely my own. If you’d like to collaborate or discuss job opportunities, please connect with me on LinkedIn or via Medium.

Coder Legion - Recent posts tagged ssh

Build a small reusable Linux checklist in FastRemote

Choose four tasks

Test each command yourself

Paste before executing

Connect output to a decision

Keep the library maintainable

My Servers Get Scanned Every 40 Seconds. Here's How I Stopped Caring — And Fixed It Anyway

Myth #1: Changing the SSH Port Is "Security"

The Actual Deadbolt: SSH Hardening That Isn't Theater

Default-Deny Firewall, Because "Allow Everything, Block What I Notice" Isn't a Strategy

Fail2ban vs CrowdSec: Pick a Fighter

Patch the Old Stuff. No, Really, the Old Stuff

The IP-Reputation Illusion Is Over

Troll Them Back: Tarpits Are Underrated and Extremely Funny

Least Exposure: Turn Off What You're Not Using

The Layered Reality Check

Keeping a Web-Backed SSH Terminal Alive Across SwiftUI Navigation

Why rebuilding is not a harmless refresh

Separate four lifetimes

Mount once, then deactivate

Preserve the WKWebView object, not necessarily its attachment

Hand focus back before detaching

Freeze hidden geometry

Keep output flowing without flooding the UI

Test transitions, not just steady states

The broader rule

Now That You've Purchased Your VPS, Let's Make It More Secure...

Introduction

Create a Sudo User and Disable Root Login

Commands

Creating a Sudo (Superuser Do) User

The UFW (Uncomplicated Firewall) Firewall

Commands

Change the default SSH port from 22 to something obscure

Commands

Protect your Ubuntu server from automated brute-force password guesses: Fail2Ban

What is Fail2Ban

Why Consider Fail2Ban

Limitations of Fail2Ban

Commands

Conclusion

How to Expose Localhost to the Public Using Nginx and SSH Tunnels

The Architecture

Step 1: The Remote Server (Nginx)

Step 2: The Local Bridge

Why this is "Unlimited"

Troubleshooting Common Gotchas

Conclusion

How does SSH work and how can it be set up?

How SSH Works

1. The Handshake

2. Authentication

3. Encryption Layers

How to Setup SSH

Step 1: Install the SSH Server

Step 2: Generate SSH Keys (Recommended)

Step 3: Copy the Key to the Server

Step 4: Connect

Conclusion

Simple backups using Rsync with SSH

Create your ssh keys

Create a backup script

Execute the script

Conclusion

The Quest Continues: Porting the Word Game With AsyncSSH

The Spark of an idea

Finding the Right Tool: Paramiko vs AsyncSSH

Two Paths and a Relearning

Bridging Game and Server

The Game Goes Live