gitextensions
gitextensions copied to clipboard
gitextensions
Initial clone cannot initialize submodules if ssh password is set
Do you want to request a feature or report a bug?
Bug
What is the current behavior?
On the remote we have a repository with submodules. If I clone the remote repo and enable submodule initalisation, GitExtensions is not pulling the submodules but rather quiting with a 'permission denied' error. See the attached image. The permission denied error occurs because I have personal password on my ssh public key.
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.
See above
What is the expected behavior?
When I run the command git clone --recurse-submodules -j8 <remote> I get prompted for my personal ssh public key password. After entering the password, the submodules are initalized properly. So I would expect that GitExtensions is also prompting me for the password, but it doesn't.
Environment you encounter the issue:
- GitExtensions version: 2.51
- GIT version: 2.14.3.windows.1
- OS version: Windows 7
Did this work in previous version of GitExtensions (which)? Not able to specify.
Suggest changing the title to: Initial clone cannot initialize submodules if ssh password is set
I ran into this. If your SSH private key has a password and you use OpenSSH, then submodule update will fail because the password is not presented. I guess it might just be on first initialize, but I had figured it would happen any time. I had the user recreate a new SSH public/private key pair without a password, and it successfully updated the submodule.
The same issue likely occurs when asked to verify an unknown host (in a normal repo, or at the command line, a yes/no prompt is given to authorize the storage of the fingerprint), which appears to be the problem submitted in this poorly worded bug report: Issue 2523, which appears to be open since 2014...
Note: You should be able to get around this using PuTTY, though it takes quite a bit of work to get the authentication client setup and running, have it launch automatically at startup, etc., but then you'll just need to enter the password for the private key once per startup.
This is why I use putty.
On Wed, May 29, 2019, 8:40 PM LightCC [email protected] wrote:
I ran into this. If your SSH private key has a password and you use OpenSSH, then submodule update will fail because the password is not presented. I guess it might just be on first initialize, but I had figured it would happen any time. I had the user recreate a new SSH public/private key pair without a password, and it successfully updated the submodule.
The same issue likely occurs when asked to verify an unknown host (in a normal repo, or at the command line, a yes/no prompt is given to authorize the storage of the fingerprint), which appears to be the problem submitted in this poorly worded bug report: Issue 2523 https://github.com/gitextensions/gitextensions/issues/2523, which appears to be open since 2014...
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gitextensions/gitextensions/issues/5073?email_source=notifications&email_token=AA3WDMJQC7PANJKM4NCP5GTPX4PBDA5CNFSM4FEW64O2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWRAQBY#issuecomment-497158151, or mute the thread https://github.com/notifications/unsubscribe-auth/AA3WDMML3GIJ4PZTQ6PJ5W3PX4PBDANCNFSM4FEW64OQ .
I can reproduce this reliably, and have been able to for many versions of GitExtensions, including the latest at the time of this writing (v3.4.3.9999 with Git 2.28.0.windows.1).
Whenever I try to clone a repository from within GitExtensions that contains submodules, and those submodules require SSH authentication, the clone of the main repository succeeds but the clone of the submodules fails due to lack of authentication.
It works perfectly if I execute
git clone --recurse-submodules -j8 git@path:repository.git
from the Git Bash prompt, so it is not an issue with my configuration. It is just a problem in GitExtensions.
I have GitExtensions set up to use OpenSSH. I suspect the problem is GitExtensions not properly loading the SSH key before executing Git commands. The Git Bash prompt does this upon startup.
I do not want to use PuTTY with GitExtensions. Please fix this bug so that GitExtensions properly supports OpenSSH!
another workaround:
I have just experiences that same issue
$ git version
git version 2.28.0.windows.1
while issuing git submodule init in PowerShell
I switched to git bash and issued the same command.
It showed a nice UI password prompt. I entered a password for my ssh key and everything worked fine.
another workaround: I have just experiences that same issue $ git version git version 2.28.0.windows.1 while issuing
git submodule initin PowerShell I switched to git bash and issued the same command. It showed a nice UI password prompt. I entered a password for my ssh key and everything worked fine.
Same here. Was using Windows Terminal based on powershell and was unable to enter password since no prompt appeared. Switching to git bash fixed it for me, and showed the password prompt correctly.
I am also having this issue. For now I guess the "solution" is to just use Git Bash when cloning and updating a repository with submodules?
Do you get a password prompt when using the Console Emulator?
No.
Just for refreshing after a year... Currently the best workaround (for me, without using putty) is:
- copy the command executed by GitExtensions (i.e:
git ...) from the first line of the process window, - open a Git bash console (Win key to open Start Menu, and type "git bash"),
-
cd <yourWorkingDir> - paste the command
git ...
