What platforms does Pluto Door support?

Pluto Door is currently available for macOS (12 Monterey and later, both Apple Silicon and Intel). Windows and Linux versions are in development and coming soon.

Is Pluto Door a one-time purchase or subscription?

One-time purchase. You pay $12 once and own it forever. All future updates within the same major version are included for free.

Is my data private with Pluto Door?

Absolutely. Pluto Door is 100% local-first. Your SSH keys, passwords, and connections never leave your machine. All connection credentials and your OpenAI API key are stored encrypted in macOS Keychain. The only network call the app makes is a one-time license verification.

How does the AI assistant work in Pluto Door?

The AI assistant uses your own OpenAI API key to communicate directly with OpenAI's servers. Pluto Door never sees or stores your prompts or responses.

Can I use Pluto Door on multiple machines?

Each license key is permanently tied to 1 machine. If you want to use Pluto Door on multiple machines, you'll need to purchase a separate license for each.

Do you offer refunds?

All sales are final. We do not offer refunds. Please review the features and documentation before purchasing to make sure Pluto Door is right for you.

Host Key Verification Failed: How to Fix It Safely

You SSH into a server you've connected to a hundred times, and suddenly you're staring at a wall of capital letters:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@  WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!  @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
...
Host key verification failed.

It looks alarming — and it's meant to. But the overwhelming majority of the time, it's completely harmless. Here's what's actually happening and how to fix it the right way.

What this error means

The first time you connect to a server, SSH saves its unique fingerprint — the host key — in ~/.ssh/known_hosts. On every connection after that, SSH compares the server's fingerprint against the saved one.

Host key verification failed means the fingerprint doesn't match what's on file. SSH refuses to continue because it can't prove the server is the same machine you trusted before.

You'll see this in two situations:

A first-time or stale entry — SSH has no key, or an outdated one, for that host
"REMOTE HOST IDENTIFICATION HAS CHANGED" — the fingerprint is different from the one you saved

Why the host key changes (almost always innocent)

Before you delete anything, understand why this normally happens:

The server was rebuilt or reinstalled — a fresh OS install generates new host keys
You got a new server on a recycled IP — cloud providers reassign IP addresses constantly
The host key was deliberately rotated — a healthy security practice
You're hitting a different machine behind the same hostname or load balancer

Every one of those is legitimate. The warning is only a real red flag if none of them apply — if the server should be the exact same machine it was yesterday. In that case, stop and investigate before you connect.

The fix: remove the old key

Once you're confident the change is expected, remove the stale entry. The clean way is ssh-keygen -R:

ssh-keygen -R server.example.com

Use the exact hostname or IP from the error message. This removes just that one entry and backs up your known_hosts file automatically.

If you connect by both hostname and IP, clear both:

ssh-keygen -R server.example.com
ssh-keygen -R 203.0.113.10

Now reconnect — SSH will ask you to confirm the new fingerprint:

ssh user@server.example.com
# The authenticity of host '...' can't be established.
# Are you sure you want to continue connecting (yes/no)?

Type yes and you're back in.

Editing known_hosts manually

If ssh-keygen -R doesn't fully clear it, the error message tells you the exact line to remove:

Offending key in /Users/you/.ssh/known_hosts:14

Open the file at that line and delete it:

nano +14 ~/.ssh/known_hosts

Modern SSH hashes the hostnames in known_hosts, so the entries look like random strings and you can't spot a host by eye — trust the line number SSH gives you, or just use ssh-keygen -R.

Verify the new key is genuine (the safe step most people skip)

If you want to be certain you're not being attacked, verify the new fingerprint against the actual server. Open the server's console through your host's web panel and run:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Compare that fingerprint to the one SSH shows you when you reconnect. If they match, you're safe. If they don't — and the server wasn't rebuilt — do not connect, and investigate.

What NOT to do

You'll find advice telling you to just switch off host key checking:

ssh -o StrictHostKeyChecking=no user@server

Don't make this a habit. It disables the exact protection that catches man-in-the-middle attacks. It's acceptable for throwaway test VMs — never for production servers — and you should never add StrictHostKeyChecking no to your config permanently.

Quick checklist

Confirm why the key changed — rebuilt server, recycled IP, or deliberate rotation
Remove the old entry: ssh-keygen -R hostname
Remove the IP entry too if you connect by both
Reconnect and confirm the new fingerprint
For production servers, verify the fingerprint from the server's console
Never leave StrictHostKeyChecking disabled

Managing keys across many servers

If you run dozens of servers, host key changes are a routine annoyance — and editing known_hosts by hand gets old fast.

A native client like Pluto Door keeps each saved connection's host key with it, flags a change clearly instead of dumping a wall of warning text, and lets you accept a rebuilt server's new key in one click — without turning verification off. You get the security of strict host checking with none of the manual file editing.

The error looks scary, but now you know the routine: confirm why it changed, clear the old key, verify the new one. Thirty seconds and you're back to work.