Bast.sh/PuTTY
Bast vs PuTTY
PuTTY defined desktop SSH for a generation of Windows operators. Bast is what that job looks like when you already live in a Unix terminal and want OpenSSH to stay in charge.
| Topic | Bast | PuTTY |
|---|---|---|
| Platform | macOS and Linux terminals | Classic Windows desktop app (ports exist elsewhere) |
| SSH stack | System OpenSSH binary | PuTTY's own SSH stack and .ppk keys |
| Sessions | ~/.ssh/config plus Bast metadata | Saved PuTTY sessions in the registry or files |
| Keys | Standard OpenSSH key files | .ppk via PuTTYgen; conversion needed for OpenSSH tools |
| Cloud VMs | Import from GCP, AWS, and Azure via their CLIs | Not built in |
| File transfers | Dual-pane SFTP in the same TUI | Separate PSCP / PSFTP tools |
| Automation | CLI with stable --json output | Mostly interactive desktop workflows |
| Price | Free and open source (MIT) | Free |
Different eras, different defaults
PuTTY solved a real problem: Windows needed a trustworthy SSH client when OpenSSH was not part of the OS story. Sessions, terminals, and key handling lived inside one desktop app, and that model still works for a lot of Windows shops.
Bast starts from the opposite default. On macOS and Linux, OpenSSH is already there. The missing piece is not another SSH implementation. It is a fast way to browse, organize, and connect to the hosts your config already knows.
Sessions vs SSH config
PuTTY sessions are a product database. Hostnames, ports, usernames, and key choices live in PuTTY's world. Other tools do not automatically share that inventory.
Bast keeps connection settings in ~/.ssh/config. That means the same hosts work in your shell, VS Code Remote, Cursor, Ansible, CI jump boxes, and Bast itself. Presentation metadata (groups, tags, notes, colors) sits beside that config instead of replacing it.
Keys without the .ppk detour
PuTTY's .ppk format made sense inside its ecosystem. It is awkward everywhere else. Teams spend real time converting keys so OpenSSH tools, cloud metadata, and agent forwarding all agree.
Bast generates, imports, and installs native OpenSSH keys on disk. No proprietary key store, no conversion tax when the rest of your stack already speaks OpenSSH.
One surface for hosts, keys, files, and cloud
With PuTTY you often juggle the session list, PuTTYgen, and separate PSCP/PSFTP binaries. Bast keeps the host picker, key manager, dual-pane SFTP, and cloud imports in one terminal UI that still hands off connections to system ssh.
Cloud sync pulls live VMs from GCP, AWS, and Azure through each provider CLI. That is a different job from saving a static PuTTY session for a box you typed in by hand.
When PuTTY is still the better choice
Keep PuTTY (or a Windows-native peer) if:
- Your primary machine is Windows and you need a mature desktop SSH client today.
- Your org standardizes on PuTTY sessions and .ppk keys as policy.
- You only need occasional ad-hoc SSH and do not care about shared OpenSSH config.
- You want a classic Windows GUI terminal rather than a terminal-native TUI.
Bast is not trying to be PuTTY on Windows. It is the OpenSSH-native answer for people who already work in macOS or Linux terminals.
Moving from PuTTY sessions to Bast
- Convert important .ppk keys to OpenSSH format and place them under
~/.ssh(or import them with Bast's key tools). - Recreate sessions as OpenSSH host blocks in
~/.ssh/config(Host, HostName, User, Port, IdentityFile, ProxyJump). - Install Bast on macOS or Linux. It discovers existing config and adds one managed Include for hosts you create inside Bast.
- Use Files for SFTP and cloud sync when inventory should come from the provider instead of a static session list.
Install Bast
One command. Then run bast and connect with the OpenSSH you already trust.
curl -fsSL https://bast.sh/install | shLatest release v0.7.1
Prefer the short version? See the Bast homepage or read the docs.