> ## Documentation Index
> Fetch the complete documentation index at: https://docs.slipway.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# SSH access

> Connect to a running service from your own terminal with a standard SSH client.

Every running service can be reached over SSH from your own machine — the same shell the
console's **Shell** tab gives you, but in your terminal, and usable by anything built on
`ssh`: one-off commands, `scp`, and your editor's remote-SSH.

```bash theme={"system"}
ssh websvc-a1b2c3d4e5f6@ssh.onslipway.sh
```

The username is the **service's id** (the `websvc-…` shown on the service page and in every
service link). There is one endpoint — `ssh.onslipway.sh` — and the username is what selects
which service you land in; you never connect to a per-service hostname. It drops you into a
shell in that service's newest running deployment, in the same container the console shell
uses.

SSH access is the same plan capability as the web shell. On a plan without it, the
connection is refused with a message rather than opening.

## Authenticating

Two ways, either works:

* **An SSH key you've registered.** Add your public key in **Account → SSH Keys** (or with
  `sw ssh-keys add ~/.ssh/id_ed25519.pub`). This is the usual path, and the only one that
  works with `scp` and editor remote-SSH.
* **A CLI token as the password.** If a client prompts for a password, paste a token from
  `slipway login`. Handy for a quick one-off without registering a key.

Keys are tied to your user, not to an org — like GitHub's. What a connection can reach is
decided per-session by your org membership and the shell capability, exactly as the web
shell is.

## Running a one-off command

Append a command to run it non-interactively and get its exit code back — useful in scripts
and CI:

```bash theme={"system"}
ssh websvc-a1b2c3d4e5f6@ssh.onslipway.sh './manage.py migrate'
```

## Managing your keys

**Console**

In **Account → SSH Keys**: add a key (paste the contents of a `.pub` file), see each
key's fingerprint and when it was last used, and remove keys you no longer want.

If you signed in with GitHub, **Import from GitHub** lists the public keys already on
your GitHub account and lets you pick which to add — no copy-paste.

**CLI**

```bash theme={"system"}
sw ssh-keys list
sw ssh-keys add ~/.ssh/id_ed25519.pub --name laptop
sw ssh-keys remove <key-id>
```

## Notes

* **A sleeping service wakes when you connect.** SSH says so, wakes it and connects once
  it is up, which can take up to a minute. The web shell does not wake anything, so wake it
  from the console first.
* **A paused service does not.** Pausing is a deliberate stop, and nothing but you will
  undo it. SSH says the service is paused rather than making you wait; start it from the
  console or with `sw services start <service>`, then reconnect.
* **The container needs a shell.** A distroless or shell-less image has nothing to drop you
  into; the same is true of the web shell.
* **Paste public keys only.** Never paste a private key — the field wants the single line
  from a `.pub` file (`ssh-ed25519 AAAA… you@host`).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.