ssh install tells a missing .ssh from one it cannot enter (closes #10)

The first sftp connection now lists ~/.ssh before it fetches
authorized_keys. The file reads as empty in just two cases: sftp reports
~/.ssh itself as not there, or the listing succeeds and the fetch then
reports the file as not there. A directory that is there but cannot be
entered, or a file that cannot be read, fails the run and writes nothing,
so a ~/.ssh whose mode shuts the user out is no longer read as a host
with no file and replaced by one holding the new key alone. The write
connection makes ~/.ssh and sets 0700 only when the read found none; an
existing directory keeps its mode.

Model: opus-4-8

README.md

@@ -94,22 +94,24 @@ Adds the `pub` line to `~/.ssh/authorized_keys` on the host. No command is run
 on the host: the file is fetched, changed here, and written back with the
 system `sftp` client in batch mode.
 
-The first connection fetches `~/.ssh/authorized_keys`. The file reads as empty
-only when `sftp` reported that file as not being there — the one line naming
-that path. The same wording anywhere else in the session does not count: `ssh`
-writes `No such file or directory` about an `-i` it cannot find, on a session
-that then authenticates through the agent. When `sftp` failed for any other
-reason — the file is there and cannot be read, the connection did not come up —
-the tool prints what `sftp` said and exits with status 1 without writing
-anything, rather than put a file back holding the new key alone. What `sftp`
-cannot tell apart is a missing file and one in a directory it cannot enter, so a
-`~/.ssh` whose mode shuts the user out reads as a host with no file; the second
-connection sets that mode to `0700` and writes, as on a host that has none. If
-an identical line is already in the file, the tool prints
-`already present` and connects no further. Otherwise the line is added (after a
-newline, if the file did not end with one) and a second connection:
+The first connection lists `~/.ssh` and then fetches
+`~/.ssh/authorized_keys` from it. The file reads as empty in two cases only:
+`sftp` reported `~/.ssh` itself as not being there, or the listing came up and
+the file was not in it. Any other outcome of that connection fails the run — a
+`~/.ssh` that is there but cannot be entered, an `authorized_keys` that is there
+but cannot be read, or a connection that did not come up — and the tool prints
+what `sftp` said and exits with status 1 without writing anything, rather than
+put a file back holding the new key alone. The listing is what tells a missing
+directory from one shut to the user, which `sftp` reports on a fetch the same
+way; the wording of a missing file elsewhere does not count either, since `ssh`
+writes `No such file or directory` about an `-i` it cannot find on a session
+that then authenticates through the agent. If an identical line is already in
+the file, the tool prints `already present` and connects no further. Otherwise
+the line is added (after a newline, if the file did not end with one) and a
+second connection:
 
-- creates `~/.ssh` and sets it to mode `0700`;
+- makes `~/.ssh` and sets it to mode `0700`, but only when the first connection
+  found none; a `~/.ssh` that was already there keeps the mode it had;
 - uploads the new file as `~/.ssh/authorized_keys.keyfunc-<random>` and sets it
   to mode `0600`;
 - renames that file over `~/.ssh/authorized_keys`.