DEV Community: Rafi Bagaskara Halilintar

PHP2Shell: Find and Patch Every PHP Server You Run (2026)

Rafi Bagaskara Halilintar — Thu, 22 Oct 2026 19:13:23 +0000

On October 21, 2026, the PHP project shipped emergency releases for PHP2Shell, two critical bugs in the PHP engine itself, tracked as CVE-2026-109618 and CVE-2026-109619. They allow unauthenticated remote code execution and remote reads of worker memory, and they don't depend on your application code. A "Hello World" script on an affected version is enough. This guide is the practical part: how to find every PHP runtime you're actually serving traffic with, patch it, confirm the old workers are gone, and look for signs someone got there first.

Quick Summary: What You'll Learn

What PHP2Shell is and which setups are at risk
Why php -v can lie to you about what's serving requests
How to patch on Debian/Ubuntu, RHEL-family, Docker and FrankenPHP
Temporary mitigations if you can't patch today, and their limits
Log signals worth checking for exploitation

What is PHP2Shell, and is my server affected?

PHP2Shell is the name Wiz Research gave to a set of memory-safety bugs in how PHP handles fatal errors, mostly out-of-memory errors, while it processes a request. An interrupted request can leave corrupted internal state behind, and a later request handled by the same worker reuses it. Wiz chained these into pre-authentication RCE against the latest WordPress, Drupal and Joomla container images, and separately showed that an attacker can read chunks of worker memory, which can include passwords, tokens and API keys from other requests.

Per the PHP security advisory:

Fixed versions: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
At risk: every PHP installation serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team rates mod_php as highest risk, because the demonstrated exploit fires before any application code runs.
PHP 8.1 and older get no upstream release. Your distribution or LTS vendor may ship a backport; the PHP team also published minimal source backports for 7.4, 8.0 and 8.1 for people building from source.
Affected range: Wiz reports every release back to PHP 5.4 is hit by at least one of the bugs.

If you run anything on PHP, assume you're affected until you've checked.

How do I find which PHP versions are actually serving traffic?

This is where most patch rounds go wrong. The CLI binary, the FPM binary and the Apache module are separate packages with separate config, and they can be on different versions. Checking php -v over SSH tells you about the CLI only.

Start by finding what's running:

ps -eo pid,user,args | grep -E '[p]hp-fpm|[p]hp-cgi|[f]rankenphp|[l]sphp'
apachectl -M 2>/dev/null | grep -i php

The first line shows FPM masters and pools, CGI, FrankenPHP and LiteSpeed processes. The second shows whether Apache has mod_php loaded.

For PHP-FPM, ask the running binary directly rather than whatever php is on your PATH:

FPM=$(readlink /proc/$(pgrep -o php-fpm)/exe)
echo "$FPM"
"$FPM" -v

pgrep -o picks the oldest matching process, which is the FPM master. If readlink prints a path ending in (deleted), the binary on disk was replaced by an update but the old master is still running the previous code. That server is not patched yet, whatever the package manager says.

For containers, check inside each one:

docker ps --format '{{.Names}}\t{{.Image}}'
docker exec <container> php -v

For FrankenPHP, the PHP version is embedded in the binary. A small script run through its CLI mode tells you which one:

echo '<?php echo PHP_VERSION, PHP_EOL;' > /tmp/phpver.php
frankenphp php-cli /tmp/phpver.php

Distro packages: why the version number isn't the whole answer

Debian, Ubuntu and RHEL often backport security fixes into the version they already ship instead of moving to upstream 8.3.36 or 8.2.35. A package can be fixed while php -v still prints an older-looking number. Check the package changelog for the CVE instead:

# Debian / Ubuntu
apt-get changelog php8.3-fpm | grep -E 'CVE-2026-10961[89]'

# RHEL / Alma / Rocky
rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961[89]'

Swap the package name for whatever you run (libapache2-mod-php8.3, php8.2-cgi, and so on). No match means your vendor hasn't shipped the fix for that package yet, or you're on a repo that doesn't track it.

One specific warning from the PHP advisory: if you rely on the volunteer-run rpms.remirepo.net, it did not have updates on disclosure day. The advisory recommends switching to distribution packages or building from source so you can patch immediately.

How do I patch PHP for PHP2Shell?

The patch itself is ordinary. The part people skip is restarting every worker.

On Debian or Ubuntu:

sudo apt update
sudo apt install --only-upgrade 'php8.3*'
sudo systemctl restart php8.3-fpm

On RHEL-family systems:

sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm

If you use mod_php, restart Apache (systemctl restart apache2 or httpd), since the module lives inside the Apache workers. For Docker, pull or rebuild the image on a fixed tag and redeploy. If you pin images by digest, the old digest stays vulnerable until you update it. For FrankenPHP, upgrade the binary or image to a release built on a fixed PHP version and restart the service. If you followed our Laravel with FrankenPHP guide, that means replacing the binary and restarting the systemd unit.

Then re-run the checks from the previous section. You're done with a host when the running binary reports a fixed version (or the changelog shows the CVE), readlink no longer shows (deleted), and the master process started after the update:

ps -o lstart= -p $(pgrep -o php-fpm)

What can I do if I can't patch today?

The PHP team is explicit that these measures reduce exposure to specific attack paths and do not make an installation safe. Use them to buy hours, not weeks.

Disable session upload progress. Set session.upload_progress.enabled=0 in php.ini, the FPM pool or the server config, then restart every worker. Setting it with ini_set() or a .user.ini file does not help, because the bug fires during request parsing, before those apply.
Lower request size limits. post_max_size = 8M if the app takes no uploads, 32M if it does, with upload_max_filesize below it. Enforce limits on request body size, multipart part count and header count at the proxy too.
Remove the controllable memory-limit failure. The advisory suggests memory_limit=-1, set where applications can't override it, plus a container or cgroup memory limit as the availability boundary. Don't use RLIMIT_AS or RLIMIT_DATA for this; those can trigger the vulnerable allocation failure.
On PHP 8.5, set fatal_error_backtraces=0 and restart workers.

In an FPM pool, php_admin_* values can't be overridden by the application:

; /etc/php/8.3/fpm/pool.d/www.conf
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 4M

Remember the CLI has its own php.ini on most distros (/etc/php/8.3/cli/ vs /etc/php/8.3/fpm/ on Debian). Checking php -i from the shell doesn't tell you what FPM loaded.

Several CDNs and WAF vendors, including Cloudflare and Fastly, announced rules for PHP2Shell. That's a useful layer, but it only covers traffic that actually goes through them. Anything reachable directly by IP bypasses it.

How do I check whether a server was already exploited?

Wiz notes these bugs fire below the application layer, so application logs may show very little. The signals they recommend looking for:

Unusual multipart requests followed by memory-limit errors or repeated HTTP 500s
Unexpectedly large or malformed PHPSESSID cookies in responses
Unexplained PHP worker churn

A first pass on a typical nginx + FPM box:

grep -h 'Allowed memory size' /var/log/php*-fpm.log /var/log/nginx/error.log 2>/dev/null | tail -50
grep -h 'exited on signal' /var/log/php*-fpm.log 2>/dev/null | tail -50
awk '$9 == 500' /var/log/nginx/access.log | wc -l

The first finds out-of-memory fatals, the second finds workers that crashed (segfaults are worth a closer look), and the third counts 500s in the current access log, assuming the default combined format. None of these proves exploitation on its own. A cluster of all three around the same multipart POSTs is what deserves an incident.

If anything looks wrong, treat it as a compromise of everything that process could read: rotate database passwords, API keys and session secrets the app uses, and invalidate active sessions. The memory disclosure bug means secrets can leak without any code execution. Then check the host itself, including authorized_keys, cron entries and new users, as you would after any RCE. The complete guide to SSH security covers what to look at on the access side.

Where termique fits

None of this needs special tooling, but it gets tedious past a handful of servers. If you manage your hosts in termique, a few things help. Save the version checks above as snippets and run them in each session instead of retyping them. Snippets sync as plaintext, which is fine for commands like these but not for anything containing a secret. On Pro, incident investigation can run read-only commands across several selected hosts and assemble the results into a report, which suits the log checks in the last section; anything that changes the system still asks you first. And on shared hosts with command logging turned on, you get a record of who ran the patch and when, which is the question someone will ask later. More on that in what a per-command audit log actually catches.

FAQ

Is updating WordPress, Drupal or Laravel enough?

No. The bugs are in PHP itself, not in the CMS or framework. You need a fixed PHP build, and every worker running it, regardless of what the application is.

I'm on PHP 8.1 or older. What now?

There's no upstream release for 8.1 and older. Check whether your distribution or LTS vendor shipped a backport (the changelog check above), build from the PHP team's source backports for 7.4 to 8.1, or use this as the push to move to a supported version.

Does `php -v` tell me if I'm patched?

Only for the CLI, and only if you're on upstream version numbers. Check the running FPM, CGI or Apache module binary, and on distro packages check the changelog for the CVE IDs.

Is a WAF or CDN enough protection?

It reduces exposure for traffic routed through it. It does not protect a server that's reachable directly, and the PHP team's position is that updating is the only complete fix.

Do I need to rotate secrets even if I patched quickly?

If your servers were exposed and you see the log signals above, yes. The memory disclosure path can leak credentials without leaving the kind of trace an RCE would. If logs are clean and you patched early, rotation is a judgment call; for internet-facing apps that handle payments or auth, it's cheap insurance.

If you're juggling a lot of servers this week, termique is free to try.

termique v0.7.0 – a redesigned workspace

Rafi Bagaskara Halilintar — Mon, 19 Oct 2026 12:30:40 +0000

termique v0.7.0 is a big one. The whole workspace is rebuilt around one content panel, the investigation page is redesigned, and underneath that sits a long list of reliability, privacy and accessibility fixes.

Update from the in-app updater when the prompt appears, or grab a fresh build from the download page.

Features

A redesigned workspace. A top bar and an Explorer sidebar now frame a single content panel, replacing the old sidebar and tab strip. Empty and success states get new illustrations.
Calmer lists. Each list's views now sit in one dropdown next to its title instead of a row of controls.
Monitoring at a glance. The monitoring detail view shows live resources as one strip instead of donut charts.
A redesigned investigation page. Commands are grouped into one step list you can skip, edit or run inline, next to a case file that shows the status, the hosts involved and the report verdict.
Investigations always reach their report. A failed turn can be retried without retyping it, and a step that doesn't name a host asks which host to run on.
Command logging is off by default for new hosts. The share dialog offers to turn it on when it's off.
Recover from a changed host key. When a host's key has changed, you can forget the old key and reconnect, behind a clear warning and a confirmation.
Keyboard resizing. Split panes, the Files view and the assistant panel can be resized from the keyboard.
Smaller minimum window size, so the app fits small laptop screens and scaled displays.

Command logging is now a choice you make per host. Hosts you already have keep their current setting, and when you share a host without logging, the share dialog tells you and lets you turn it on.

A changed host key is either a server rebuild or something you should stop and look at. The new flow doesn't skip that decision, it just stops you from having to edit known_hosts by hand once you've made it. If you're not sure which case you're in, compare the new fingerprint with the server's before you confirm. Host key verification explained walks through how to check.

Improvements

The master password lockout can no longer be reset by restarting the app.
Commands proposed by the assistant are checked more strictly before they run automatically.
The AI assistant no longer receives your hosts' addresses or ports, only each host's label and user.
Share recipients are looked up without putting their email address in a URL.
Assistant messages no longer load remote images.
Credentials are removed from command logs before upload.
Error reports no longer contain IP addresses, host names, email addresses or tokens.
Faster startup: each page now loads the first time you open it, and charts and message formatting load only when needed.
An upgraded SSH engine that fixes several security issues.
If your system's web view is too old to draw the new interface, the app now tells you what to update.

Your server addresses now stay on your machine when you use the assistant. It only sees the name you gave a host and the user you log in as.

Two of these are worth calling out. Labels are often less sensitive than addresses, so if your host labels contain internal hostnames or IPs, the assistant will still see those; rename them if that matters to you. And command logs are stored on termique's backend without end-to-end encryption, which is why stripping credentials before upload, plus logging being opt-in for new hosts, matters. If you're deciding whether to turn logging on for a shared host, what a per-command audit log actually catches covers the tradeoff.

Bug fixes

Fixed SSH sessions hanging or blocking each other when one channel is slow, and connections left open after a failed connect.
Fixed shared hosts disappearing after a background refresh, and save conflicts when editing a host.
Fixed terminal scrollback being lost when tabs are merged or the app locks.
Commands that the assistant or an investigation runs on a shared host now appear in the owner's activity log.
Fixed the window freezing during database, keychain and file operations.
Rounded window corners now stay when the window is maximized on macOS.
The command palette, Explorer controls and previously unlabelled buttons now work properly with the keyboard and screen readers.

Update to v0.7.0 to get the new workspace and these fixes.

Keep reading

ssh-keygen Best Practices for 2026: Keys, Rounds, FIDO

Rafi Bagaskara Halilintar — Mon, 19 Oct 2026 12:17:38 +0000

Quick Summary: What You'll Learn

The one ssh-keygen command most people should run in 2026, and what each flag in it does.
How to choose between Ed25519, RSA, FIDO-backed -sk keys and the new post-quantum hybrid mldsa44-ed25519 type that OpenSSH 10.6 enabled.
Why -a (KDF rounds), a real comment and a passphrase matter more than key size.
The file permissions, ~/.ssh/config lines and fingerprint checks that keep a good key from becoming a bad habit.

Most ssh-keygen best practices guides stop at "use Ed25519". That's still the right default in 2026, but it's only one decision out of five. The key type, the passphrase, the KDF rounds that protect that passphrase, the comment that tells you which laptop the key came from, and where the private key ends up afterwards all decide whether a stolen file is a non-event or an incident. OpenSSH also shipped changes this year that affect new keys, so some older advice is out of date. Every flag below is checked against the current OpenBSD ssh-keygen(1) manual and the OpenSSH release notes.

What is the best ssh-keygen command to run in 2026?

For a personal key on a laptop or workstation, this is a sane default:

ssh-keygen -t ed25519 -a 100 -C "you@laptop-2026-10" -f ~/.ssh/id_ed25519_laptop

What each part does:

-t ed25519 picks the key type. Since OpenSSH 9.5 (October 2023), Ed25519 is what ssh-keygen generates when you pass no -t at all, so this flag is mostly there to be explicit in scripts and docs.
-a 100 sets the number of bcrypt_pbkdf rounds used to encrypt the private key with your passphrase. The manual's default is 32. Higher means slower passphrase checks and slower offline cracking if the file is stolen. More on choosing a number below.
-C "you@laptop-2026-10" sets the comment. The default is user@host, which tells you almost nothing two years later. Put the device and the date in it.
-f ~/.ssh/id_ed25519_laptop names the file, so the key doesn't silently overwrite an existing id_ed25519.

When it prompts for a passphrase, give it one. The manual's own guidance is that good passphrases are 10 to 30 characters, not simple sentences, with mixed character classes. A random phrase from a password manager is easier than inventing one.

Which SSH key algorithm should you choose?

ssh-keygen -t accepts ecdsa, ecdsa-sk, ed25519, ed25519-sk, mldsa44-ed25519 and rsa in the current manual. In practice, the choice looks like this:

Ed25519: the default for new keys. Small public keys, fixed length (-b is ignored), and supported by OpenSSH since 6.5 (January 2014). Pick this unless something below applies.
RSA: only for systems that can't do Ed25519 (some network gear, older appliances, a few hosted services). The manual's default size is 3072 bits and it calls 3072 "generally sufficient". Many teams use -b 4096 anyway; that's fine, just slower.
ECDSA: no strong reason to choose it over Ed25519 for user keys today. -b selects the curve (256, 384 or 521); other values fail.
Ed25519-SK / ECDSA-SK: keys backed by a FIDO authenticator (a hardware security key). The private part never leaves the hardware. Best choice when you have the token and your servers run a modern OpenSSH.
mldsa44-ed25519: a hybrid signature that combines ML-DSA-44 (a post-quantum scheme) with Ed25519. Read the next section before adopting it.

One thing people still mix up: OpenSSH 8.8 disabled the old ssh-rsa signature algorithm (RSA with SHA-1) by default. That did not make RSA keys obsolete. The same RSA key signs with rsa-sha2-256 or rsa-sha2-512, and the release notes say exactly that. If an old RSA key stopped working against a new server, the usual culprit is a client or server too old to negotiate SHA-2 signatures, not the key itself.

To see which key types your local OpenSSH supports:

ssh -V
ssh -Q key

Is the post-quantum mldsa44-ed25519 key ready to use?

OpenSSH 10.4 (July 2026) added mldsa44-ed25519 as an experimental, off-by-default composite signature scheme. OpenSSH 10.6 (released 2026-10-06) enabled it as a standard algorithm and dropped the @openssh.com suffix the experimental version used. The release notes are explicit that keys generated with the experimental support must be regenerated.

ssh-keygen -t mldsa44-ed25519 -a 100 -C "you@laptop-2026-10-pq" -f ~/.ssh/id_mldsa44_laptop

Practical guidance for now:

Both ends need an OpenSSH release that understands the new algorithm name. A server on an older release won't accept the key, so check with ssh -Q key on the server side too.
If you generated one of these during the experimental 10.4/10.5 window, regenerate it on 10.6 rather than debugging why it stopped matching.
Keep an Ed25519 key alongside it. Post-quantum key exchange already protects session traffic against record-now-decrypt-later attacks in recent OpenSSH releases; the signature side matters for a future attacker forging authentication, which is a slower-moving risk. There's no rush to make the hybrid key your only key.
Third-party clients, libraries and hosted git services may not parse it yet. Test before you depend on it.

How many -a rounds should you use?

The -a value only matters for keys that have a passphrase. It controls how much work it takes to test one passphrase guess against a stolen private key file. The man page states the default (32) and that higher numbers mean slower verification and more resistance to brute force; it doesn't prescribe a value.

A workable way to pick one: generate a throwaway key with a candidate value, then time how long unlocking it takes on your slowest machine.

ssh-keygen -t ed25519 -a 100 -N 'test-only-passphrase' -f /tmp/kdf-test -q
time ssh-keygen -y -P 'test-only-passphrase' -f /tmp/kdf-test > /dev/null
rm /tmp/kdf-test /tmp/kdf-test.pub

-y reads the private key and prints the public key, so it has to decrypt the file first. If it takes a fraction of a second, you can go higher. If it's annoying on every connection, an agent (below) means you only pay it once per session. Don't type real passphrases on the command line like this; -N and -P end up in shell history. It's fine for a throwaway test key only.

You don't need a new key to raise the rounds on an existing one. Changing the passphrase re-encrypts the file and accepts a new -a value (you can keep the same passphrase):

ssh-keygen -p -a 100 -f ~/.ssh/id_ed25519_laptop

Should every SSH key have a passphrase?

For keys that live on a laptop or a phone, yes. A passphrase turns "someone copied my ~/.ssh folder" from an immediate compromise into "they have an encrypted file and a lot of guessing ahead of them". The manual is blunt about the downside: there is no way to recover a lost passphrase. If you lose it, you generate a new key and replace the public key everywhere. Store it in your password manager.

The exceptions are keys that a machine has to use unattended: host keys (the manual says these must have an empty passphrase), and automation keys on CI runners or deploy boxes. For those, compensate on the server side instead. Restrict what the key can do in authorized_keys (a from= source address and a forced command, for example), or use short-lived certificates so a leaked key expires on its own. Our comparison of SSH certificates vs plain public keys covers when certificates are worth the setup.

To stop typing the passphrase on every connection, let ssh-agent hold the decrypted key for the session. In ~/.ssh/config:

Host *
    AddKeysToAgent yes

With AddKeysToAgent yes, the key and passphrase are added to a running agent the first time the key is loaded from a file. If you hit "incorrect passphrase supplied to decrypt private key" along the way, our passphrase troubleshooting guide walks through the usual causes.

When should you use a FIDO hardware key with ssh-keygen?

When the key protects something you'd hate to lose, and you already carry a security key. With ed25519-sk, the file in ~/.ssh is only a key handle. The actual private key sits inside the authenticator and can't be exported, so copying the file without the hardware gets an attacker nothing.

ssh-keygen -t ed25519-sk -O resident -O verify-required -C "you@yubikey-2026-10"

-O resident stores the key handle on the authenticator itself, so you can load it on another computer with ssh-keygen -K (or ssh-add -K). The manual notes the tradeoff: storing both parts on the device makes a stolen authenticator more useful to an attacker. Resident keys typically require a PIN on the token.
-O verify-required requires user verification (currently a PIN) for each signature, not just a touch. Not every authenticator supports it.
By default every signature needs a physical touch. -O no-touch-required turns that off, and sshd refuses such signatures unless the authorized_keys entry explicitly allows it. Leave the touch requirement on.

The caveats: the server needs a modern OpenSSH to accept -sk keys, and you should register a second authenticator as a backup, because losing the only token locks you out the same way a lost passphrase does.

How should you name, store and check SSH keys?

Generating the key well is half of it. These habits keep it manageable later.

One key per device. If a laptop is lost, you revoke one public key instead of rotating a key that lives on four machines. The comment is how you tell them apart in authorized_keys, which is why -C "you@laptop-2026-10" beats the default. Our guide to managing multiple SSH keys across devices has a naming scheme that scales past three machines.

Fix a bad comment without regenerating:

ssh-keygen -c -C "you@laptop-2026-10" -f ~/.ssh/id_ed25519_laptop

Permissions. ssh(1) ignores a private key file that other users can read, and recommends that ~/.ssh itself is accessible only by you:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519_laptop
chmod 644 ~/.ssh/id_ed25519_laptop.pub

Point each host at the right key. Without this, ssh offers every key in your agent in turn, which can trip a server's MaxAuthTries before it reaches the right one:

Host prod-bastion
    HostName bastion.example.com
    User deploy
    IdentityFile ~/.ssh/id_ed25519_laptop
    IdentitiesOnly yes

IdentitiesOnly yes tells ssh to use only the configured identity files, even when the agent holds others.

Install the public key, and only that one:

ssh-copy-id -i ~/.ssh/id_ed25519_laptop.pub deploy@bastion.example.com

-i makes sure only the key you named gets installed, with the comment from the .pub file, rather than everything in your agent.

Check fingerprints. When you add a key to a server or a git host, compare fingerprints instead of eyeballing base64:

ssh-keygen -lf ~/.ssh/id_ed25519_laptop.pub

SHA-256 is the default fingerprint hash. If you lost the .pub file, regenerate it from the private key with ssh-keygen -y -f ~/.ssh/id_ed25519_laptop > ~/.ssh/id_ed25519_laptop.pub.

Plan the rotation now. Put the year in the comment and you'll know which keys are overdue. Our SSH key rotation best practices post covers how often to rotate and how to do it without locking anyone out, and the team key management guide covers offboarding.

What ssh-keygen advice is outdated in 2026?

"Generate RSA 2048." Still accepted by sshd (the RequiredRSASize default is 1024 bits), but there's no reason to create new 2048-bit RSA keys when Ed25519 is available.
"DSA is fine for old systems." OpenSSH 10.0 removed DSA support entirely. Any remaining id_dsa key needs replacing.
"You must pass -t ed25519 or you get RSA." Not since OpenSSH 9.5; Ed25519 is the default.
"Use -o for the new key format." The OpenSSH private key format has been the default for years, and current ssh-keygen doesn't list -o in its synopsis at all. Use -m PEM only when an old tool insists on PEM.
"Post-quantum SSH keys aren't a thing yet." As of OpenSSH 10.6 they are, as a hybrid. They're just early.

Where does termique fit into SSH key management?

termique is a free, native ssh manager we build, with end-to-end encrypted credentials. On the key side, it does a few specific things:

Generate or import. You can generate ed25519 (recommended) or rsa keys in Settings → SSH keys, or import an existing private key in OpenSSH or PEM format, including passphrase-protected keys. For FIDO -sk keys and the new mldsa44-ed25519 type, generate with ssh-keygen as shown above.
Encrypted before it's stored. Private keys are encrypted on your device with a key derived from your master password before they're written locally or synced. The sync backend stores ciphertext only. Hosts, groups and snippets sync as plaintext metadata, so don't put secrets in host names or snippets. The security page has the full model.
Same keys on desktop and phone. Keys sync across macOS, Windows, Linux and iOS, so the key you use from your laptop is available in the mobile app without emailing a private key to yourself.

That last point is a real tradeoff against the one-key-per-device advice above. A synced key is one key on several devices: convenient, and protected by end-to-end encryption, but a lost phone means rotating that key everywhere it's authorized. If your policy is strictly one key per device, generate a separate key on each device instead; termique handles both, and the comment you set still tells you which is which.

FAQ

What is the most secure SSH key algorithm in 2026?

For everyday use, Ed25519 backed by a FIDO authenticator (ed25519-sk), because the private key can't be copied off the hardware. Without a hardware key, plain Ed25519 with a strong passphrase. The mldsa44-ed25519 hybrid adds post-quantum resistance to signatures, but needs OpenSSH 10.6 on both ends and isn't widely supported outside OpenSSH yet.

Is RSA 4096 better than Ed25519?

Not in any way that matters for most users. RSA 4096 is secure, but keys and signatures are much larger and slower. The manual considers 3072-bit RSA sufficient. Use RSA only for systems that can't handle Ed25519.

How do I add a passphrase to an existing SSH key?

Run ssh-keygen -p -f ~/.ssh/your_key. It prompts for the old passphrase (press Enter if there is none) and the new one twice. Add -a 100 to raise the KDF rounds at the same time.

Should I use the same SSH key on every computer?

Usually not. One key per device means a lost laptop costs you one revocation instead of a rotation across every server. Syncing one key across devices with end-to-end encryption is a valid choice for convenience, as long as you accept that losing any of those devices means rotating it.

What does the -C flag do in ssh-keygen?

It sets the key's comment, which is stored in the private key file and appended to the public key line in authorized_keys. It has no security effect, but a comment like you@laptop-2026-10 tells you which device and year a key belongs to when you audit a server.

Try termique free

If you want your keys, hosts and snippets on every machine you use, with private keys end-to-end encrypted before they leave the device, download termique and start on the free plan.

Alright my first weekly challenge on Hacktoberfest!

Rafi Bagaskara Halilintar — Fri, 02 Oct 2026 20:20:47 +0000

Rafi Bagaskara Halilintar

Oct 2

Kas Rumah: a receipt-reading expense tracker for my wife that never leaves our laptop

#devchallenge #weekendchallenge #hf26challenge

5 min read

Kas Rumah: a receipt-reading expense tracker for my wife that never leaves our laptop

Rafi Bagaskara Halilintar — Fri, 02 Oct 2026 20:13:35 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

My wife runs our household money. Groceries, the electricity bill, gas refills, the occasional ShopeeFood order, envelopes for weddings. She has tried expense apps before and every one of them died the same way: typing each purchase by hand is tedious, so after a week the app gets ignored and the receipts pile up in her bag.

Kas Rumah ("house cash" in Indonesian) removes the typing. She can take a photo of a receipt, upload a bank transfer screenshot, or type something like beli sayur 45rb sama galon 20rb ("bought vegetables 45k and a water gallon 20k"). A local Gemma model turns it into categorized expenses, she checks them on a review screen, and once a week she gets a short summary in casual Indonesian telling her where the money went and which budget is running hot.

Everything runs on our laptop at home. Her phone talks to it over our Wi-Fi.

To be upfront: she hasn't used it yet. I built it over this weekend, and everything in this post was tested with sample receipts and screenshots, not ours. Handing it to her is the next step, and her first week with it will tell me more than any test set did.

Demo

Code

masitings / kasrumah

Kas Rumah — household expense tracker. Local Gemma 3 (Ollama) reads receipts / transfer screenshots / typed notes. Laravel 13 + Inertia + React, 100% offline AI.

Kas Rumah

A household expense tracker for a spouse managing the family's budget. Snap a photo of a receipt or bank transfer screenshot, or type a casual note like "beli sayur 45rb" — a local Gemma 3 model via Ollama parses it into a categorized expense. Nothing ever leaves this laptop: zero cloud AI, zero third-party expense APIs.

Stack

Laravel 13 + Inertia (React, TypeScript) with the official starter kit
SQLite or MySQL database
Ollama running gemma3:4b (vision-capable) at http://127.0.0.1:11434
Money is stored as integer rupiah (no decimals)
UI copy is casual Indonesian; code, comments, and commit messages are English

One-time Setup

composer install
npm install
cp .env.example .env
php artisan key:generate
php artisan migrate

Make sure Ollama is installed and the model is downloaded:

ollama pull gemma3:4b   # ~3.3 GB
ollama serve

Optional overrides in .env:

OLLAMA_URL=http://127.0.0.1:11434
OLLAMA_MODEL=gemma3:4b

Development

composer run dev   # sail-style:

…

View on GitHub

How I Built It

Stack: Laravel with the React starter kit (Inertia), MySQL, and Gemma 3 4B running through Ollama on an M5 MacBook with 16 GB of RAM.

The app has five screens: Catat (record), Review, Pengeluaran (expenses), Ringkasan (summary), and Budget. The interesting part is how little I ask the model to do.

Reading receipts

One ExpenseExtractor service sends either an image or a line of text to Ollama's /api/chat. Two things made the 4B model usable:

Structured outputs. Instead of asking nicely for JSON, I pass a JSON schema in Ollama's format field, with the category list as an enum. The model cannot invent a category, and I never parse broken JSON.
Separate prompts for images and text. My first version used one prompt for both and said "one receipt is one expense, don't split items." That rule made the model return nothing for sayur 45rb sama galon 20rb, because the text clearly has two expenses. Splitting the prompts fixed it. The image prompt also tells the model to ignore payment lines like TUNAI (cash), KEMBALI (change) and QRIS, because on the first run it logged the cash handed to the cashier as a second expense.

Images are downscaled to 1600px before they go to the model, which keeps each receipt at about 4 seconds.

Nothing the model returns is saved directly. Every result lands on the Review screen as a draft, and rows with low confidence are highlighted. She fixes what is wrong and taps Simpan.

The weekly summary

I don't let the model do math. PHP computes this week's total per category, the 4-week average, and budget usage, then hands Gemma those numbers with a prompt that says to use only them. Gemma's job is just to turn a small JSON object into three to five friendly sentences. A 4B model is good at that and bad at arithmetic, so that is the split.

Voice input and iPhone photos for free

I planned to add Whisper for voice notes. Then I realized the iPhone keyboard already has a dictation button, so the text field is the voice input. Same story with HEIC photos: setting accept="image/jpeg,image/png" on the file input makes iOS Safari convert to JPEG before upload, so the server never sees a HEIC file.

Where my AI coding agent cheated, and the honest numbers

I used an AI coding agent for a lot of the build and gave it a regression test: three receipt photos and four text samples with known answers. It came back with 7/7 passing. Then I read the prompt. It had written the expected totals and store names from the test receipts straight into the instructions. The tests passed because the answers were in the question.

I made it remove every value from the test set, split the fixtures into a tuning set and a holdout set it was only allowed to run once, and run every case three times. These are the real numbers for gemma3:4b on that small set of sample receipts and screenshots:

Field	Correct
Amount (images)	4 of 5
Category (images)	5 of 5
Merchant name (images)	2 of 5
Text input	4 of 4

Amounts and categories, the fields that matter for a household budget, are solid. Merchant names are weak: it could not read a stylized store logo, and for a transfer screenshot it picked the payment app instead of the person receiving the money. One pharmacy receipt read 23,000 instead of 25,000, the same way every time. Those are all things the Review screen catches in a second, so I stopped tuning there instead of chasing a nicer number.

Why Does Open Innovation Matter?

This app reads my family's receipts and bank transfer screenshots. Those show what we buy, where we shop, who we send money to, and sometimes account details. I was not willing to send that to a third-party API, and I don't think my wife would have agreed to use it if I had. With Gemma running locally, the photos and the numbers stay on a laptop in our house.

It also costs nothing to run. A cloud vision API would be cheap per call, but it would still be a monthly bill for a tool whose whole point is helping us spend less.

And because the model is open, I could pick the size that fits the job. A 4B model on a laptop is fast enough for a person waiting with their phone in hand, and the design (strict schema, PHP does the math, a human confirms) makes up for what a small model gets wrong. If it ever falls short, I can swap the model with one line in .env without touching the app.

Prize Categories

Best Use of Gemma

Adding server monitoring to my SSH manager without opening a second connection

Rafi Bagaskara Halilintar — Mon, 29 Jun 2026 03:20:16 +0000

I use my SSH manager every day. I also use a separate monitoring tool every day. For a long time I just accepted that these were two different things.

Then one day I was SSH'd into a server that was behaving weird. I wanted to check if it was CPU or memory, but I had to open a different app, find the server in there, and wait for the dashboard to load. It took maybe 15 seconds. Not a huge deal. But it broke my flow every single time.

I already had an SSH connection open to that server. Why was I opening a second thing just to see what was happening to it?
That's what pushed me to build server monitoring directly into Termique, the SSH manager I've been working on.

The interesting part: reusing the existing SSH connection

SSH connections aren't just for terminals. The protocol supports multiple channels over a single TCP connection. You can have a terminal session running in one channel while sending short exec commands through another channel on the same connection.

That's how the monitoring feature works. When you open the metrics panel for a server, Termique creates a separate exec channel on the existing SSH connection and polls /proc/stat for CPU, /proc/meminfo for RAM, and /proc/loadavg for system load. Short-lived commands, called on an interval, over the connection you already have open.
No second SSH handshake. No separate auth. Just another channel on the same pipe.

The tradeoff: you do need an agent

I want to be upfront about this. The monitoring feature requires a small agent installed on each server. It's not agentless.

I considered going agentless, relying entirely on /proc reads through exec channels. That works fine on most Linux servers. But the agent makes it easier to handle edge cases properly and opens the door for future features like alerts and longer history retention. Without it, I'd be fighting a lot of fragile shell parsing.

If you're managing Linux servers, it's a one-command install. Non-Linux systems aren't supported yet. That's a real limitation and something I'm still working through.

Where it fits

The goal isn't to replace something like Netdata or Grafana. Those are great for what they do. The monitoring in Termique is specifically for the moment you're already in your terminal and just want to know if the server is struggling. CPU, RAM, disk. At a glance. Without switching apps.

It's a consolidation thing, not a monitoring platform.

Current status

The feature is still in development. I'm targeting a release in the next Termique update. If you want to try it when it's out, or just poke around the existing SSH manager in the meantime, it's at termique.app. Free tier available, Pro is $5/month.

If you've built something similar or have opinions on how you handle server monitoring in your day-to-day, I'd love to hear it in the comments.

Submitting to App Store and Play Store as a solo developer - what actually happened

Rafi Bagaskara Halilintar — Sat, 06 Jun 2026 11:14:04 +0000

I submitted Termique to the App Store and Play Store three days ago. It's live now. Here's what the process actually looked like, because most guides make it sound cleaner than it is.

The part nobody talks about - the assets

Before you even think about submitting, you need screenshots. Not just any screenshots, specific sizes for specific devices. App Store wants iPhone screenshots, iPad screenshots, and if you support Mac, Mac screenshots too.

The iPad one caught me off guard. Termique is an iPhone app. I don't have an iPad. But Apple requires iPad screenshots anyway. So I ran the simulator, took the screenshots, and moved on. It's annoying but it takes maybe 30 minutes once you know it's coming.

For the actual design I used Figma templates from the community, there are free ones that handle all the sizing automatically. That part wasn't bad. The bad part was not knowing I needed it until I was already mid-submission.

The rejection

I got rejected. It happens. The reasons were straightforward, a missing screenshot size and something about content rights information that I hadn't filled in. Both fixable in under an hour.

The thing about App Store rejection is it's not as dramatic as it sounds. They tell you exactly what's wrong. You fix it. You resubmit. That's it.

Three days from submission to live

I submitted on day one. Got feedback the same day. Fixed everything, resubmitted on day two. Approved and live on day three.

I was expecting weeks. I got three days. That was the biggest surprise of the whole process.

Play Store was similar, faster review, slightly different requirements, but nothing that required starting over.

What I'd tell myself before starting

Make sure your legal pages are ready before you submit. Privacy policy, terms of use, all of it. Both stores will ask for links during submission and you can't just skip them. Having those ready saved me a round trip.

The other thing, your app doesn't have to be perfect. It has to work. There's a difference. Some things weren't fully polished when I submitted Termique. But nothing was broken in a way users would notice. That's the bar. Don't wait for perfect, you'll never ship.

The actual hard part

Honestly the submission process itself wasn't the hard part. The hard part was building something worth submitting in the first place.

Termique is available on the App Store and Play Store now. If you manage servers and want an SSH manager that actually syncs across all your devices, give it a try.

termique.app

Why I chose Tauri over Electron for my SSH manager

Rafi Bagaskara Halilintar — Wed, 03 Jun 2026 11:33:54 +0000

When I started building Termique, I knew one thing for sure: it had to feel fast.

An SSH manager is a tool you open constantly. You switch between servers, you check logs, you run commands. The last thing you want is to wait for your app to load. So when I started evaluating my options for building a cross-platform desktop app, Electron was the obvious first choice, but it didn't take long for me to realize it wasn't the right one.

The Electron problem

Electron is everywhere. VS Code, Slack, Discord, all built on Electron. And for good reason: it's mature, well-documented, and lets you build desktop apps with web technologies.

But the tradeoff is real. Electron ships with its own copy of Chromium and Node.js. Every Electron app is essentially a browser running your app inside it. The result? My early build was hitting around 100MB just for the installer. For an SSH manager, that felt absurd.

And it wasn't just the bundle size. The app felt heavy. Not broken, not unusable, just heavy. That sluggish feeling every time you open it, that half-second delay before things respond. For a tool you open dozens of times a day, that adds up fast.

Discovering Tauri

Tauri takes a different approach entirely. Instead of bundling its own browser engine, it uses the OS's native webview, WebKit on macOS, WebView2 on Windows, WebKitGTK on Linux. The result is dramatically smaller bundle sizes and native performance.

When I switched Termique to Tauri, the Windows installer went from ~100MB down to 12MB. That's not a small improvement, that's a completely different category of app.

But what surprised me more was the performance difference. Tauri just feels fast in a way that's hard to explain. Snappier startup, smoother interactions. I'm not sure exactly what's happening under the hood, but the difference is noticeable immediately.

It wasn't all smooth sailing

I'll be honest, Tauri has its quirks. The one that frustrated me the most early on was something embarrassingly simple: the close button didn't work.

When I first got the app running, clicking the X to close the window did absolutely nothing. I had to force quit every single time. It took me a while to figure out the fix, but that kind of thing is part of working with a newer framework, the documentation isn't always as comprehensive as Electron's, and some things you just have to figure out yourself.

Was it worth it?

Yes, without question.

For Termique specifically, the lightweight nature of Tauri isn't just a nice-to-have, it's part of the product's identity. An SSH manager should feel like a native tool, not a browser tab pretending to be one. 12MB installer, fast startup, no bloat. That's exactly what I wanted.

If you're building a developer tool where performance and trust matter, I'd seriously consider Tauri. It's not as plug-and-play as Electron yet, but the tradeoffs are absolutely worth it.

Termique is available at termique.app, free to try, and built entirely with Tauri.

I got locked out of my own servers. So I built my own SSH manager.

Rafi Bagaskara Halilintar — Thu, 28 May 2026 18:12:58 +0000

A while back, I switched devices.

Simple enough, right? Except I was on Termius Free and apparently
host sync is a Pro feature. So everything I had set up, hosts, SSH
keys, credentials, none of it carried over. I had to start from scratch.

That was the moment I thought: why am I paying for something that
holds my own data hostage behind a paywall?

So I built Termique.

One month. One developer. Zero co-founders.

I started in early May. Today, Termique is a fully working SSH manager
for macOS, Windows, and Linux, built with Tauri, React, Hono,
PostgreSQL, Firebase, and Cloudflare Workers.

The hardest part wasn't the code. I built most of it with AI assistance.
The real challenge was figuring out what to build, which features
actually matter, how sync should work securely, and what should never
leave your device.

The second hardest part? Security auditing. Making sure nothing leaks
that shouldn't. Credentials stay encrypted on your device. The server
never sees plaintext. No telemetry on your sessions.

What it does today

Add a host on your laptop. Open your desktop. It's already there, IP,
port, SSH key and all. No re-setup. No copy-pasting credentials between
machines.

That's the thing I'm most proud of. It sounds simple, but that's
exactly the point.

Where we are

12 users, still very early. Launching on Product Hunt on June 15th.
Free plan available, Pro is $5/month, half of what frustrated me in
the first place.

If you've ever been annoyed by Termius pricing or just want an SSH
manager that doesn't feel bloated, I'd love for you to try it and
tell me what you think.

termique.app

DEV Community: Rafi Bagaskara Halilintar

PHP2Shell: Find and Patch Every PHP Server You Run (2026)

Quick Summary: What You'll Learn

What is PHP2Shell, and is my server affected?

How do I find which PHP versions are actually serving traffic?

Distro packages: why the version number isn't the whole answer

How do I patch PHP for PHP2Shell?

What can I do if I can't patch today?

How do I check whether a server was already exploited?

Where termique fits

FAQ

Is updating WordPress, Drupal or Laravel enough?

I'm on PHP 8.1 or older. What now?

Does php -v tell me if I'm patched?

Is a WAF or CDN enough protection?

Do I need to rotate secrets even if I patched quickly?

termique v0.7.0 – a redesigned workspace

Features

Improvements

Bug fixes

Keep reading

ssh-keygen Best Practices for 2026: Keys, Rounds, FIDO

What is the best ssh-keygen command to run in 2026?

Which SSH key algorithm should you choose?

Is the post-quantum mldsa44-ed25519 key ready to use?

How many -a rounds should you use?

Should every SSH key have a passphrase?

When should you use a FIDO hardware key with ssh-keygen?

How should you name, store and check SSH keys?

What ssh-keygen advice is outdated in 2026?

Where does termique fit into SSH key management?

FAQ

What is the most secure SSH key algorithm in 2026?

Is RSA 4096 better than Ed25519?

How do I add a passphrase to an existing SSH key?

Should I use the same SSH key on every computer?

What does the -C flag do in ssh-keygen?

Try termique free

Alright my first weekly challenge on Hacktoberfest!

Kas Rumah: a receipt-reading expense tracker for my wife that never leaves our laptop

Kas Rumah: a receipt-reading expense tracker for my wife that never leaves our laptop

What I Built

Demo

Code

masitings / kasrumah

Kas Rumah — household expense tracker. Local Gemma 3 (Ollama) reads receipts / transfer screenshots / typed notes. Laravel 13 + Inertia + React, 100% offline AI.

Kas Rumah

Stack

One-time Setup

Development

How I Built It

Reading receipts

The weekly summary

Voice input and iPhone photos for free

Where my AI coding agent cheated, and the honest numbers

Why Does Open Innovation Matter?

Prize Categories

Adding server monitoring to my SSH manager without opening a second connection

The interesting part: reusing the existing SSH connection

The tradeoff: you do need an agent

Where it fits

Current status

Submitting to App Store and Play Store as a solo developer - what actually happened

The part nobody talks about - the assets

The rejection

Three days from submission to live

What I'd tell myself before starting

The actual hard part

Why I chose Tauri over Electron for my SSH manager

The Electron problem

Discovering Tauri

It wasn't all smooth sailing

Was it worth it?

I got locked out of my own servers. So I built my own SSH manager.

One month. One developer. Zero co-founders.

What it does today

Where we are

Does `php -v` tell me if I'm patched?