Why I rewrote AutoPuTTY from scratch

19 August 2026 · Denis Torresan

I have been using AutoPuTTY since 2009. Not on and off, and not alongside something else — it has been the tool, every working day, for seventeen years.

I tried the alternatives. Dozens of them, over the years. Almost all of them made the same mistake: they wanted to be the terminal, the file manager, the session recorder and the tab manager, when what I needed was a list of machines and a double click. AutoPuTTY understood that. It was an address book, not another terminal, and it stayed one.

So this is not an article about a tool that let me down. It is an article about what happens when a tool is right for seventeen years and your own work grows out from under it.

What changed was my list, not the tool

In 2009 I had a handful of servers. Today it is more than twenty clients and around fifty projects, and every one of them brings machines with it.

A flat list stops working long before that. People know it, which is why they invent hierarchy inside the only field they have — names like Customer: server, so that at least the related machines sort next to each other. I did it for years. It is a workaround that works, right up until you have fifty prefixes and you are scrolling to find one of them.

The second thing was the dark theme. That sounds like a preference and for me it is not one: I spend most of the day in front of the screen, and over the years I have dropped every program that stayed bright. By the end, the tool I opened most often was the one lighting up my desk.

Neither of those is a flaw. They are things the tool was never asked to be, in the years when it was written.

I sent a patch first

Before thinking about any of this, I did the ordinary thing: I contributed. Connections needed a comments field — somewhere to note which customer a machine belongs to, or why it has an unusual port — so I wrote it and opened a pull request in January 2023.

It is still open, which is completely normal for software maintained in someone's spare time. Nobody who gives their work away owes a stranger a merge. But it did tell me something useful about planning: if I wanted folders and a dark theme as well, that was work I would have to do myself.

To be clear about it, this is not a silent project. When I asked a question that mattered — see below — I had an answer within four days.

The file format is from another era

Which brought me to the format. I wanted my list somewhere I could back up properly, so I sat down to read autoputty.xml — and what I found there is the reason the new one is not a fork.

Fields are encrypted with Triple DES in ECB mode, keyed by an MD5 hash of a passphrase. When no master password is set, that passphrase is a constant that ships in the source, which is what lets the program open your list without asking you anything. That was a common way to do exactly that in small Windows utilities of the late 2000s.

It is not how anyone would build it today. A key that travels with the program can be read by anyone who has the program; ECB reveals structure in what it encrypts; MD5 is fast where a key derivation function needs to be slow; and there is no authentication tag, so a modified file goes unnoticed. Seventeen years is a long time in cryptography, and none of this was settled when the choice was made.

Hostpad still contains the code that reads it, in a class called LegacyAutoPuttyCipher. It is there to import old lists, and never to write new ones.

The jump host in the username

One more thing came out of reading the format. AutoPuTTY supports SSH jump hosts, and stores them like this:

proxyuser@proxyhost:port#user

Four pieces of information — the jump user, the jump host, its port and the real user — packed into the username field with two separator characters. It is a neat way to add a feature without breaking a file format, and it works. I used it for years without complaint.

I wanted it as fields. In Hostpad a jump host is a JumpHost object with a host, a user and a port, and the launcher turns it into a real proxy command:

plink -batch -P <port> <user@host> -nc %host:%port

The importer knows the old syntax and unpacks it for you. It does the same for the Customer: server naming habit, which becomes an actual folder and an actual name.

Why not a fork

So: keep my patch, replace the crypto, add folders and a dark theme. That is a fork, and it was the obvious move. I started one.

Which surfaced a question first. The repository carried no licence at all, and without one it is not clear that anybody may distribute a derivative, so I asked. The answer came four days later and was as generous as the rest of it: consider it GPLv3.

That cleared the way — and then I decided against the fork anyway, for two reasons.

The first is arithmetic. Once the storage format, the security layer, the connection model and the entire interface have been replaced, what is left of the original is the idea — and the idea is the part I admired, not the part I needed to change.

The second is that a fork inherits assumptions. AutoPuTTY grew over many years around a flat list and, at the beginning, a single tool. Nested folders, several protocols per host and a vault with two independent unlock paths are not features you bolt on; they change what the model has to be. Starting again was the honest way to get there, and it leaves the original where it is instead of dragging it somewhere it never meant to go.

Hostpad therefore shares no code with AutoPuTTY. It is written from scratch on .NET 10 and WPF, and it is GPLv3 — the licence r4dius named for his own work, which seemed like the right one to inherit even without a line of the code.

The decisions I would defend

The vault is always encrypted, and the default asks for nothing. AES-256-GCM, always — there is no plaintext mode to forget to switch on. Without a master password the data key is wrapped by DPAPI and tied to your Windows account: no password to type, and the file is useless to anyone who copies it off the machine. Set a master password and it opens on another computer too, which is what makes a backup worth having. Whether it asks at startup is a separate choice from whether it can travel.

The iteration count lives in the file. Passwords are derived with PBKDF2-HMAC-SHA256 at 600,000 iterations, and that number is written into the vault rather than compiled into the program. When it needs to go up — and it will, which is the lesson of every format that came before — existing vaults keep opening and pick up the new count the next time they are saved.

Changing the master password rewraps a key. It does not re-encrypt the contents, which is why it is instant however long your list is, and the whole reason the data key is kept separate from the password key.

Saving cannot truncate the file. Every write goes to a temporary file and swaps via File.Replace, keeping the previous version until the swap succeeds. Losing a server list to a crash mid-save is the kind of failure nobody forgives.

The launchers do not launch anything. Each one builds a command and hands it back as a LaunchPlan; something else decides to start a process. That sounds like a technicality, but it is what lets the argument building for six connection types be tested without opening a single window — including the awkward parts, like the plink command above.

What it is not

It is not a terminal. It does not embed PuTTY, it launches it. It does not render RDP, it hands off to mstsc. That is the lesson of seventeen years with AutoPuTTY and of every alternative I abandoned: the tools you already have are better at their jobs than a reimplementation of them inside a connection manager would ever be.

It is Windows only, because DPAPI and the tools it drives are. And it is not code-signed: a certificate costs money the project does not have, so SmartScreen will warn you the first time. What you get instead is a build you can trace — every release is produced by a workflow on GitHub's runners from a tagged commit, and the SHA-256 of each file is written into the release notes by that workflow rather than by me.

If you are still on AutoPuTTY

There is an importer, and it leaves your original file untouched. Point it at autoputty.xml and it brings across the passwords, the comments, folders recovered from name prefixes, jump hosts unpacked into fields, and the tool paths if you want them. If the file had a master password, it asks for it.

Afterwards, rotate the passwords that were in it — see the note above for why. And if AutoPuTTY is still doing what you need, keep using it. It did that for me for seventeen years, and it was never the tool that changed.