SSH Client for Chromebook (2026): Terminal, Secure Shell, Crostini, or an Android App

The short answer

Your Chromebook already has an SSH client and you probably don’t need to install anything. The Terminal app that ships with ChromeOS has had managed SSH connections since ChromeOS 103, and — this is the part most guides get wrong — it works whether or not you have turned on the Linux development environment. Open Terminal, add a connection, enter user@host, done.

There are four routes in total, and they are not interchangeable. Pick by what you actually need:

One route to cross off immediately: the “Secure Shell App” is dead. Google phased out Chrome Apps, and per Google’s own enterprise documentation, ChromeOS 138 in July 2025 was the last release with support for user-installed Chrome Apps on ChromeOS. Any tutorial telling you to install the Secure Shell App was written before that and will send you to a store page that no longer installs anything useful. The extension is the survivor.

For reference throughout: current stable at the time of writing is ChromeOS 150, released 16 July 2026.

Route 1: the built-in Terminal app

This is the fastest correct answer for most people, and it is under-documented because it arrived quietly.

How to use it:

1. Open the launcher, search Terminal, open it.
2. In the tab strip, click the + and choose to add an SSH connection (older builds label the button Add SSH).
3. Fill in username, hostname, port, and optionally SSH arguments like -i or -J.
4. Save it. It now sits in the Terminal’s connection list and opens in one click.

Under the hood this is Google’s Secure Shell code — the same project as the extension, living at chromium.googlesource.com/apps/libapps. Historically the SSH engine was nassh, built on Chrome’s Native Client. After NaCl was deprecated in 2020 in favour of WebAssembly, it was replaced by wassh, a WASM SSH client, and both the Terminal and the extension now default to wassh.

What you get: ed25519 and RSA public-key auth, password auth, an xterm-compatible terminal, saved connections, and a working copy/paste story. No account, no cloud, nothing leaves the device.

What you don’t get: an ~/.ssh/config file in the sense you’re used to (connections are per-entry UI fields, not a text file you can version-control), no rsync, no jump-host convenience beyond typing the -J flag yourself, and no file browser. It is a connector, not a workstation.

Who this is wrong for: anyone managing more than a handful of hosts, or anyone who moves files regularly.

Route 2: the Secure Shell extension

The Secure Shell extension (ID iodihamcpbpeioajjeobimgagajmlibd) is Google-developed and genuinely maintained — version 0.79 was published on 20 July 2026, a healthier cadence than most SSH clients in any store.

Use it over the built-in Terminal when you want the same client on Chrome across machines — a Chromebook at home, Chrome on a Windows desktop at work — rather than one that only exists on ChromeOS. Feature-wise it and the Terminal’s SSH tabs are close relatives.

The one caveat that matters: SFTP mounting into the Files app is broken.

The old Chrome App could mount a remote path over SFTP so it appeared in the ChromeOS Files app, using ChromeOS’s fileSystemProvider API. The extension build is cross-platform by design and therefore does not carry ChromeOS-only APIs; the project’s own app-to-extension migration notes record that SFTP mounting broke with the Manifest V3 changes. Command-line SFTP still works fine. Mounting-into-Files, as a feature you can rely on, does not.

So if your workflow was “mount the server, drag files in the Files app,” that specific pleasure died with Chrome Apps. Your options are a dedicated SFTP client, or scp/rsync from the Linux container below.

Route 3: real OpenSSH inside Linux (Crostini)

If you want SSH to behave the way it does on a Linux laptop, stop fighting ChromeOS and turn on the Linux development environment.

Setup: Settings → Advanced → Developers → Linux development environment → turn on. ChromeOS provisions a Debian container inside a VM. You’ll be asked for a disk size; the minimum is 10 GB, and you can resize later from the same settings page. On ChromeOS Flex, this only works on certified models — check before planning around it.

Then:

sudo apt update && sudo apt install -y openssh-client
ssh-keygen -t ed25519 -C "chromebook"

Now you have everything: ~/.ssh/config with Host aliases and ProxyJump, ssh-agent, ssh-copy-id, scp, rsync, mosh, tmux. If you have never written one, the SSH config file is the highest-leverage thing to set up here, and ed25519 vs RSA covers why the -t ed25519 above is the right default in 2026. To get the public key onto a server, ssh-copy-id works normally from this container.

Two things worth knowing:

• ChromeOS can SSH into your container. It is reachable at penguin.linux.test, which is handy for testing an sshd setup, or for connecting from the Terminal app’s SSH tab into your own Linux environment.
• The container is a VM, with its own network. This is not a detail — see the next section. It is the source of most “why can’t I reach X” confusion on ChromeOS.

Who this is wrong for: managed school and enterprise Chromebooks, where administrators frequently disable the Linux development environment entirely, and low-storage 32 GB devices where 10 GB is a real sacrifice.

Route 4: an Android SSH app

Most Chromebooks sold in the last several years run Android apps from the Play Store, which means the entire Android SSH ecosystem is available to you — the same apps people use on phones, on a device with a real keyboard.

This is not the obvious choice for a Chromebook-only user. It becomes the obvious choice when one of these is true:

• You already SSH from your phone, and you want one host list, one set of keys, one client — not a ChromeOS-shaped setup that ends at the lid.
• You need a file browser next to the terminal, which is exactly the gap the Files-app SFTP mount used to fill.
• The machines you want aren’t publicly exposed — a home server behind CGNAT, a VPS with port 22 locked to an allowlist — and you’d rather not run a separate VPN app.

Termius is the mature cross-platform option: Windows, macOS, Linux, iOS, Android, with an encrypted vault syncing hosts, keys and snippets. The free tier is a usable single-device client; paid starts at Pro, $10 per user per month billed annually (termius.com/pricing). We mapped where the paywall falls in Termius free vs paid. Be aware the Android app is phone-shaped — on a large Chromebook display, window-resizing behaviour has been a long-standing complaint.

TermAI — our app, so weigh this accordingly — is an iOS and Android SSH/SFTP client built for operating servers away from a desk. On a Play-enabled Chromebook it installs as an Android app. What it adds over the built-in routes:

• SFTP with a two-pane file browser alongside the terminal, which the extension can no longer give you in Files.
• Built-in Tailscale, so a home server or firewalled VPS is reachable without exposing port 22 and without a second VPN app — and, importantly on ChromeOS, without straddling two network stacks (next section). Tailscale SSH covers the model; access your home server from anywhere covers the CGNAT case.
• AI command suggestions, assistant-style. You describe the goal; it writes the journalctl/systemctl/awk line onto your input line and waits for you to press enter. It never executes on its own. On a production box that is the correct default, and we argued it at length in letting AI run shell commands safely.

Pricing: the free tier is 5 AI requests per day with SSH and SFTP unlimited; Pro is $2.99/month; Team is $7.99/seat/month.

The honest limitation: it is an Android app running on ChromeOS, not a native ChromeOS app — so on ChromeOS Flex, which has no Play Store at all, this route doesn’t exist. On Flex you have Terminal, the extension, and Crostini (certified models only). The best SSH app for Android surveys this category properly if you want the wider field.

The ChromeOS networking trap

This is the part that costs people an evening, and almost nothing written about Chromebook SSH mentions it.

ChromeOS runs three separate network worlds. ChromeOS itself, the Android runtime, and the Crostini VM each sit behind their own NAT layer. Things that look like they’re on the same machine are, from the network’s point of view, three different machines.

The consequence bites hardest with mesh VPNs. If you run Tailscale as an Android app on the Chromebook and also run tailscaled inside your Linux container, those two nodes generally cannot connect directly to each other — tailscale/tailscale#432 documents ChromeOS-Android and Crostini falling back to relayed DERP traffic because of STUN problems across the NAT layers. Everything technically works, slowly, and you spend an hour wondering why latency is terrible.

Pick one place to run Tailscale. Tailscale’s own Chromebook install docs point users at the Android app, and there’s a decent security argument for it: the Linux VM never sees the raw Tailscale credentials, and multiple VMs can share the one network path. The trade is that some features don’t reach inside the container — Taildrop can’t send files from within the Linux container, for instance.

Practical rule of thumb:

• SSH from an Android app → run Tailscale as an Android app. Coherent, one stack.
• SSH from Crostini → run Tailscale inside Crostini. Also coherent.
• Both at once → expect relayed connections and confusion. Don’t.

If you’re still deciding whether a mesh VPN is the right tool at all, Tailscale vs WireGuard is the comparison.

Where your keys live, and how to not lose them

Each route stores private keys somewhere different, and the failure modes differ:

Three things follow.

A Powerwash wipes all of it. ChromeOS’s reset-to-factory is a normal troubleshooting step that support articles hand out casually. It deletes the Linux container along with everything else. Back up the container — ChromeOS has a built-in Linux backup and restore in Settings — and copy that backup file off the device, not into Downloads, which is also wiped.

Generate a new key rather than exporting an old one. Exporting a private key means it passes through a clipboard or a file, which is exactly the exposure that keeping it inside an app avoided. Generate a fresh ed25519 key in whichever route you’re adopting, append its public key to ~/.ssh/authorized_keys on each host from a session that already works, verify the new client connects on a cold start — force-close, reopen, connect — and only then remove the old key.

Keep a second way in. A provider web console (DigitalOcean, Hetzner, OVH), IPMI, or a physically reachable keyboard. This matters more on a Chromebook than on a laptop, because the device is designed to be disposable and replaced — which is a feature right up until it’s your only path to a production box.

Worth checking while you’re here: your Chromebook’s Auto Update Expiration date. Devices released from 2021 onward get 10 years of updates under Google’s current policy; older ones may already be out of support, and an out-of-support browser is a bad place to keep SSH keys.

What the Android merge means for your choice

This part is directional rather than settled — but the direction is on the record.

At Qualcomm’s Snapdragon Summit in September 2025, Google’s Android Ecosystem President Sameer Samat said Google is “combining ChromeOS and Android into a single platform.” The project is widely reported as Aluminium OS, an Android-based desktop OS expected during 2026. The name and device details come from reporting and leaks, not from Google; the merge itself came from Google.

What that plausibly implies for anyone setting up SSH on a Chromebook today:

• Android SSH apps are the least likely thing to break. If the destination is an Android-based desktop, apps that already run on Android are on the safe side of the transition.
• ChromeOS-specific surfaces carry the most risk. The Terminal app and the Secure Shell extension are ChromeOS- and Chrome-shaped. Google has already demonstrated willingness to retire this class of thing — Chrome Apps went from “the recommended way to SSH on a Chromebook” to unsupported in a few years.
• Crostini is the open question. A Debian container is valuable and widely used, but it’s a ChromeOS architecture, and nothing has been committed publicly about its future shape.

None of this is a reason to panic or to switch today. It is a reason to make the cheap hedge: keep your host inventory somewhere portable. A written-down ~/.ssh/config, or an app with an account you can sign into on the next device, costs nothing now and saves an afternoon later. Hosts you can only reach because a particular app on a particular Chromebook remembers them are hosts you will eventually lose.

Chromebook-specific SSH errors

“Connection timed out” on school or corporate Wi-Fi. Many managed networks block outbound port 22 outright. Test from another network — a phone hotspot works — before blaming the client. The durable fixes are running your server’s SSH on an alternate port, or a mesh VPN. SSH connection timed out walks the full diagnosis.

“Host key verification failed.” Each route keeps its own known-hosts store. Moving from the Terminal app to the extension to Crostini means re-accepting host keys three times, and each prompt is a real trust decision rather than a formality — check the fingerprint against one you obtained from the server itself. Host key verification failed covers the legitimate causes; trust on first use explains the model you’re re-enacting.

“Permission denied (publickey)” right after switching routes. Almost always the new route’s key isn’t in authorized_keys yet, or permissions on the server are wrong: ~/.ssh must be 700 and authorized_keys 600. See SSH permission denied.

Linux dev environment missing from Settings. Either the device is managed and an administrator disabled it, or it’s a ChromeOS Flex machine that isn’t certified for it. Neither is fixable from your side; use the Terminal app or an Android client.

Sessions dying when the lid closes or the Chromebook sleeps. Not a client bug, and no client fixes it. Run your work inside tmux server-side so it survives any disconnect — keeping a process running after SSH disconnects covers the patterns. It’s the same discipline that makes running Claude Code from a phone workable.

Terminal isn’t in the launcher. Search “Terminal” in the launcher rather than browsing the app grid; on some builds it stays out of the way until first invoked. If it genuinely isn’t there, install the Secure Shell extension — it does the same job.

FAQ