From ade58131d65cdbd40e0c331312ad305c1ff4299c Mon Sep 17 00:00:00 2001 From: Joakim Persson Date: Sat, 8 Aug 2026 01:24:51 +0200 Subject: [PATCH] docs(readme): use mkdir -p instead of install -d for the peer's ~/.ssh MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `install -d -m 700 ~/.ssh` was correct but wrong for the audience. This snippet gets pasted onto an arbitrary peer — a NAS, a router, a BSD box — and `install` is not in POSIX, so it is not guaranteed to be there. `mkdir -p` + `chmod` is POSIX, present everywhere, and self-evidently idempotent to a reader deciding whether it is safe to run on a machine that already has keys. Behaviour was checked rather than assumed, on both coreutils and BSD/macOS `install`: on an existing ~/.ssh it exits 0 and leaves authorized_keys intact in content and mode, but it also silently chmods the directory (755 -> 700). Desirable here, yet invisible in a doc — which is the second reason to prefer the explicit two-step form, and why the surrounding text now states outright that re-running is safe on an already-configured peer: mkdir -p is a no-op, the chmods only tighten, and appending never touches keys already listed. Verified the whole block end-to-end against a fresh HOME and one with a pre-existing 755 ~/.ssh and an older key: 700/600 in both cases, older key preserved, new line appended. --- README.md | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/README.md b/README.md index 51d46ad..e54b0ab 100644 --- a/README.md +++ b/README.md @@ -887,22 +887,25 @@ the account you will log in as** (the `User` from step 3), narrowly authorized rather than bare: ```bash -install -d -m 700 ~/.ssh +mkdir -p ~/.ssh && chmod 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`). +Both lines are safe on a peer that is already set up: `mkdir -p` is a no-op +when the directory exists, the `chmod`s only tighten, and appending never +touches keys already listed. 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