offer to add an ssh key even when one already exists

The zip option was already gone — it never came across in the port, since the
file is key material that cannot live in the repository and the script no longer
sits next to it. Pasting a public key was already the first option. What was
missing is the case where the account HAS a key: the section went straight to
hardening, so there was no way to authorise a second machine, a rebuilt laptop or
anyone else, and the original had no way to do it at all.

The same menu is now offered either way. What differs is whether it can be
declined without consequence: with no key, declining means the hardening below
refuses too, and the run says so rather than quietly moving on.

confirm() takes an optional default so this one can be [y/N]. Most questions in
this script are "do the thing you already asked for" and Enter should mean yes; a
genuine extra defaulting to yes is how people end up agreeing to things by
reflex.

A pasted key is trimmed before validation. Copying from a terminal or a password
manager routinely brings leading or trailing whitespace, and ssh-keygen will not
parse a key with it attached — which would have read as "that is not a valid
key" for a key that is perfectly fine.

Also corrected the reason unzip is in core utils, which still said it was there
to open ssh-keys.zip.

Verified: the add-another prompt appears and defaults to no, a whitespace-wrapped
key is trimmed and accepted, and the already-hardened path is unchanged.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

scripts/setup/machine-setup/machine-setup.sh

@@ -849,10 +849,26 @@ if ! skip; then
   echo "     root login:                    $(sshd_effective permitrootlogin)"
 
   # ── a key first ──
+  #
+  # The same menu whether or not there is already one, because "add another" is a
+  # real need — a second laptop, a rebuilt machine — and the original had no way
+  # to do it at all. What changes is whether the question can be declined: with no
+  # key, declining means the hardening below will refuse too, and the run says so.
+  ADD_KEY=false
   if ((KEY_COUNT == 0)); then
     echo ""
     warn "${USERNAME} has no authorised key. Password login cannot be turned off until it has one."
-    echo "     [1] paste a public key   (the contents of your ~/.ssh/id_ed25519.pub)"
+    ADD_KEY=true
+  else
+    fix_ssh_permissions
+    echo ""
+    ADD_KEY=false
+    confirm "Add another authorised key for ${USERNAME}?" n && ADD_KEY=true
+  fi
+
+  if $ADD_KEY; then
+    echo ""
+    echo "     [1] paste a public key   (one line, from your own ~/.ssh/id_ed25519.pub)"
     echo "     [2] generate a new keypair on this machine"
     echo "     [3] leave it for now"
     echo ""
@@ -866,6 +882,11 @@ if ! skip; then
       case "${SSH_KEY_CHOICE:-1}" in
         1)
           read -rp "  Paste the public key: " SSH_PASTED || fail "No answer."
+          # Trimmed: pasting from a terminal or a password manager routinely
+          # brings leading or trailing whitespace, and ssh-keygen will not parse
+          # a key with it attached.
+          SSH_PASTED="${SSH_PASTED#"${SSH_PASTED%%[![:space:]]*}"}"
+          SSH_PASTED="${SSH_PASTED%"${SSH_PASTED##*[![:space:]]}"}"
           add_authorized_key "$SSH_PASTED" && SSH_KEY_DONE=true
           ;;
         2)
@@ -883,8 +904,6 @@ if ! skip; then
       esac
     done
     KEY_COUNT="$(authorized_key_count)"
-  else
-    fix_ssh_permissions
   fi
 
   # ── then hardening, and only then ──