assistant: Set StrictHostKeyChecking yes when creating ssh remotes, and add it to the configuration for any ssh remotes previously created by the assistant. This avoids repeated prompts by ssh if the host key changes, instead syncing with such a remote will fail. Closes: #732602

1 files changed, 19 insertions, 0 deletions

diff --git a/doc/bugs/Endless_SSH_password_prompts.mdwn b/doc/bugs/Endless_SSH_password_prompts.mdwn
index 26def613f..fad730a1b 100644
--- a/doc/bugs/Endless_SSH_password_prompts.mdwn
+++ b/doc/bugs/Endless_SSH_password_prompts.mdwn
@@ -13,3 +13,22 @@ I don't understand why this is happening.
 
 ### What version of git-annex are you using? On what operating system?
 1 Nov 2013 Linux tarball on Ubuntu Raring 13.04
+
+> [[fixed|done]]; assistant now sets `StrictHostKeyChecking yes`
+> when creating ssh remotes. It also fixes up any ssh remotes it already
+> created to have that setting (unless StrictHostKeyChecking is already
+> being set).
+> 
+> So, when the host key changes, syncing with the remote will now fail,
+> rather than letting ssh prompt for the y/n response. In the local
+> pairing case, this is completely right, when on a different lan
+> and it tries to communicate with the wrong host there. OTOH, if the ssh
+> key of a ssh server has really changed, the assistant does not currently
+> help dealing with that.
+> 
+> Any ssh remotes not set up by the assistant are left as-is, so this 
+> could still happen if the ssh host key of such a ssh remote changes.
+> I'll assume that if someone can set up their ssh remotes at the command
+> line, they can also read the dialog box ssh pops up, ignore the 
+> misleading "passphrase request" in the title, and see that it's actually
+> prompting about a host key change. --[[Joey]]