Please describe the problem.
On a user Windows machine, we get an odd issue of being unable to annex get a file from an ssh remote (https://gin.g-node.org/yarikoptic/test-annex) while using an ssh key with a passphrase. The reason seems to be that 2nd invocation of ssh by git-annex does not result in the prompt for the passphrase.
I failed to reproduce locally in Windows VM machine. In my case (probably different setup of ssh etc), I 1). get passphrase prompt via external gui window (not in the same terminal); 2). do get 2nd prompt as well.
Here you can get a full log where you can see passphrase prompt for initial clone, then within get once and not after 2nd ssh call
$> grep -1 -e passphrase -e faile -e 'ssh ' test-annex-output-windows-ssh-passphrase-20211209.txt
Cloning into 'test-annex'...
Enter passphrase for key '/c/Users/mvdmlab/.ssh/id_rsa':
remote: Enumerating objects: 58, done.
--
# manually added to grep output for more consistent extract
(NWB) PS D:\NWB\test_annex> cd .\test-annex\
(NWB) PS D:\NWB\test_annex\test-annex> git annex --debug get annexed
--
Disabling ssh connection caching.
[2021-12-09 10:41:16.7006865] (Utility.Process) process [14232] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","config","annex.sshcaching","false"]
--
You have enabled concurrency, but git-annex is not able to use ssh connection caching. This may result in multiple ssh processes prompting for passwords at the same time.
annex.sshcaching is not set to true
[2021-12-09 10:41:21.819308] (Utility.Process) process [9560] read: ssh ["git@gin.g-node.org","-n","-T","git-annex-shell 'configlist' '/yarikoptic/test-annex' '--debug'"]
Enter passphrase for key '/c/Users/mvdmlab/.ssh/id_rsa':
[2021-12-09 10:41:32.8083061] (Utility.Process) process [9560] done ExitSuccess
--
You have enabled concurrency, but git-annex is not able to use ssh connection caching. This may result in multiple ssh processes prompting for passwords at the same time.
annex.sshcaching is not set to true
[2021-12-09 10:41:32.8443384] (Utility.Process) process [2248] chat: ssh ["git@gin.g-node.org","-T","git-annex-shell 'p2pstdio' '/yarikoptic/test-annex' '--debug' 'dfff8737-36e2-4a1c-8206-bca071a5294d' --uuid 2a0fa804-1bd6-4298-aa55-4dc2d250eeac"]
[2021-12-09 10:41:34.1335084] (Utility.Process) process [2248] done ExitFailure 255
Transfer failed
--
No other repository is known to contain the file.
failed
[2021-12-09 10:41:34.1405139] (Utility.Process) process [14104] done ExitSuccess
--
[2021-12-09 10:41:34.1475217] (Utility.Process) process [500] done ExitSuccess
get: 1 failed
What version of git-annex are you using? On what operating system?
Windows, 8.20211124-ga8ff96864
I do not think that git-annex is doing anything there that prevents ssh from asking for a password. Ie, it's not setting BatchMode=true, which it does do when it wants to prevent ssh from prompting for a password. That is done only when ssh connection caching is supported, which it's not on Windows.
It's running
ssh git@gin.g-node.org -T "git-annex-shell 'p2pstdio' '/yarikoptic/test-annex' '--debug' 'dfff8737-36e2-4a1c-8206-bca071a5294d' --uuid 2a0fa804-1bd6-4298-aa55-4dc2d250eeac"and that somehow fails, and the failure is at the ssh level (ssh exit status 255 means a ssh error). This might not involve a password at all. For whatever reason ssh is failing without displaying any error message.It could be something as simple as this ssh not supporting -T. Or just being broken in whatever way ssh on windows might be broken.
My suggestion is, run the ssh command yourself, and see if it exits 255, if so proceed to debugging ssh..
That does not help diagnose your problem, does it? All is says is that the problem somehow involves password protected ssh keys. But ssh is what deals with those.
You have to show that the problem is actually caused by git-annex, not by ssh, before I can really do anything about it. The obvious way to do that is to run the command as I suggested.
What is the exit status of ssh when you run that?
That would normally print out the AUTH-SUCCESS and block waiting for input from stdin. Your transcript seems to show it closing immediately after that output, unless perhaps you sent it a ctrl-d.
So perhaps stdin is not getting connected through the
ssh -T, or something could be failing on the remote end.The behavior on Windows is as you said it is going to be. See screenshot below:
https://ibb.co/cbXBgGM
Thank you. So standard input is not getting connected through the ssh to git-annex-shell, it appears.
Could you try the same command with without the -T option, and see if it allows you to interact with it? Eg, after it says "AUTH-SUCCESS", see if you can enter "test" and if it replies to that.
By not getting through to the shell, do you mean the absence of a prompt? In any case here's a screenshot of the command with and without '-T'. I first press 'Enter' once and see that Error message and then I type 'test' and press enter. Then I press Ctrl + C to exit and try the next command without '-T'. And the same result!
https://github.com/vandermeerlab/data-formats/blob/master/debug/Output2.png
Ok, you've ruled out my theory about -T, and stdin is being connected up through ssh correctly it looks like.
One other thing to try would be to enable ssh verbose debugging, by running:
git config annex.ssh-options "-v -v -v"And perhaps that will give a clue.
But I think the signs are pointing to you needing to change something about your ssh installation on Windows. Perhaps a different version of ssh for Windows would support the GUI password prompt. Normally, ssh comes from Git for Windows, which bundles a ssh, and I think that one does support the GUI prompt. Do you have some other ssh build installed?