summaryrefslogtreecommitdiff
path: root/doc/bugs/Endless_SSH_password_prompts.mdwn
blob: fad730a1b47fcddb2cc0cf4cf01a2e3a76fb604b (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
### Please describe the problem.
Yesterday I installed git-annex on two computers and paired their repos.  Today I logged back in to one of them, and as soon as the webapp loaded (autostarted in the background), it popped up an OpenSSH prompt wanting my key's password.  I typed it in, and it popped up another.  This went on several times.  When I hit Cancel instead, it popped up a prompt wanting the password for the user account on my other computer.  Even with that, once wasn't enough.

This is bad enough, but worse is that the password prompt captures the keyboard input so I can't even open my Yakuake console to kill git-annex.  Well, it's difficult and requires hitting Escape rapidly over and over until I can squeeze in a keystroke to the rest of the system.

I don't understand why this is happening.

1.  Shouldn't git-annex have installed a passwordless key on my paired system?  It did that for my remote repo.

2.  The prompt it's using has no option to remember the pasword.  I use ssh-agent, but usually by running ssh-add in a terminal.  Maybe if it would use a prompt that works with the agent it wouldn't ask for the password multiple times.  

3.  I think it's opening multiple SSH connections at once, before I've entered the password even once, so even after I enter the password, it will keep asking for it until I've entered it for every SSH process that was already started.

### 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]]