From ffd44ad9cfa336561180438f51d2aea2be271747 Mon Sep 17 00:00:00 2001 From: Joakim Persson Date: Sat, 8 Aug 2026 01:17:48 +0200 Subject: [PATCH] docs(readme): say where the authorized_keys line actually goes MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Step 2 of "Giving the container its own key for a peer" showed a correctly narrowed authorized_keys line but never named the file it belongs in, and never said which account's — the only mention of authorized_keys was an aside 35 lines further down about revoking one key per machine. A reader following the steps had a public key, a line to construct, and nowhere to put it. Now explicit: append to ~/.ssh/authorized_keys of the account named as `User` in step 3, via a heredoc that shows `>>` rather than `>` (the truncation that revokes every other key on that account), with `install -d -m 700 ~/.ssh` and `chmod 600` so the file is created correctly the first time. Adds the three failure modes that make a good key look broken, none of which announce themselves on the client: the options prefix must be on the same physical line as the key (a wrapped paste is the usual culprit), `ssh-copy-id` cannot add that prefix at all so the line must be appended by hand, and sshd's StrictModes silently ignores authorized_keys when the home directory, ~/.ssh or the file is group- or world-writable — reporting it only in the peer's own log. --- README.md | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 766a4bb..51d46ad 100644 --- a/README.md +++ b/README.md @@ -882,12 +882,28 @@ cat ~/.ssh-local/mypeer_devbox_ed25519.pub # ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEXAMPLE0000EXAMPLE0000EXAMPLE0000ex devbox-0d11ec7731c7 ``` -**2. On the peer** — authorize it narrowly rather than bare: +**2. On the peer** — append that public key to `~/.ssh/authorized_keys` **of +the account you will log in as** (the `User` from step 3), narrowly authorized +rather than bare: -``` +```bash +install -d -m 700 ~/.ssh +cat >> ~/.ssh/authorized_keys <<'KEY' from="192.168.1.0/24,192.168.4.0/24,10.8.0.7",restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEXAMPLE0000EXAMPLE0000EXAMPLE0000ex devbox-mymachine +KEY +chmod 600 ~/.ssh/authorized_keys ``` +Use `>>`, never `>` — one stray truncation revokes every other key on that +account. The options prefix must sit on the **same physical line** as the key, +comma-separated with no spaces: a paste that wrapped is the likeliest reason a +key that looks right is refused. `ssh-copy-id` cannot add that prefix, so +append by hand (or let it copy the bare key and edit the line afterwards). If +authentication still fails with no clear reason, suspect permissions — sshd's +`StrictModes` silently ignores `authorized_keys` when the home directory, +`~/.ssh` or the file itself is group- or world-writable, and says why only in +the peer's own log (`journalctl -u ssh`, `/var/log/auth.log`). + `restrict` disables pty, agent/X11 and port forwarding; append `port-forwarding` and `permitopen="127.0.0.1:"` after it if you need one specific tunnel. `from=` must list the **host's** addresses, not the