Windows - ssh config host alias for remote works in CMD and PS but not in LazyGit

[ddw360]

Windows 11 - using Powershell and/or CMD - in my project, have git configured with remotes using my host alias and SSH key. All works on the command line, however cannot get lazygit to respect the local git repo remotes. Lazygit ignores ssh-agent cached and ignores local repo git remote and tries to connect to git repo (i.e. [email protected]...) without the host name alias and associated ssh private key.

How does one make that it respect it properly. Tested with other tools, i.e. VS Code, Visual Studio -- no problems, but lazygit is a no... read documentation - wasn't obvious if a specific config is needed for things to work as intended.

[stefanhaller]

Lazygit doesn't know anything about ssh; it simply calls git. If git works on the command line in Powershell or CMD (I suspect that it doesn't for you), then lazygit will work too.

I don't have a lot of experience with Windows, so I'm not sure what to suggest in terms of trouble-shooting. My suspicion is that Powershell has a different opinion about what your HOME directory is (containing the ssh config) than, say, git bash.

Personally I'm running git bash in a Windows Terminal window, this works well for me.

[ddw360]

It does work on the command line just fine - as described in the original post. Just not in LazyGit.

…

------ Original Message ------ From "Stefan Haller" ***@***.***> To "jesseduffield/lazygit" ***@***.***> Cc "ddw360" ***@***.***>; "Author" ***@***.***> Date 2/8/2025 10:04:59 AM Subject Re: [jesseduffield/lazygit] Windows - ssh config host alias for remote works in CMD and PS but not in LazyGit (Discussion #4239)

Lazygit doesn't know anything about ssh; it simply calls git. If git works on the command line in Powershell or CMD (I suspect that it doesn't for you), then lazygit will work too. I don't have a lot of experience with Windows, so I'm not sure what to suggest in terms of trouble-shooting. My suspicion is that Powershell has a different opinion about what your HOME directory is (containing the ssh config) than, say, git bash. Personally I'm running git bash in a Windows Terminal window, this works well for me. — Reply to this email directly, view it on GitHub <#4239 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAICUDGNBU3VAXP7JSAM4EL2OZBMXAVCNFSM6AAAAABWUNAXS6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMJQGQ2TAOI>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[stefanhaller]

Ok, sorry for missing that in the original post. I have absolutely no idea why there should be a difference in behavior whether lazygit issues a git command or you type the same command at the same prompt that you lauch lazygit from. Lazygit really only calls the git commands exactly like they appear in its command log window.

Anybody else have an idea?

[ddw360]

I think the issue is that lazygit can't handle any prompt challenge for ssh request for passphrase?

Note powershell test:

Note lazygit:

I've tried:
ssh-add -k <path to my private key>
$env:GIT_SSH = C:\Windows\System32\OpenSSH\ssh.exe

Setting path to ssh in PATH environment variable, etc.

So I have just turned off my passphrase (ssh-keygen -p) and now lazygit can handle that ok. However, that reduces the security stance down a bit - if private key ever got compromised.

Sounds like a change request needed or is there a config item needed?

[stefanhaller]

It is true that lazygit doesn't support passphrase prompts on Windows, this is a well-known issue. The reason is that we still don't have a working PTY library on Windows, which would be required for this.

The recommended workaround is to get some sort of ssh agent running so that you don't have to type the passhrase (or rather, just once per login session), both on the command line and in lazygit. This is where I'm confused: in your original post you claim that lazygit ignores your ssh-agent, so it sounds like you do have one. Also, you were talking about host aliases, which I understand to be Host entries in your .ssh/config file; those have nothing to do with the PTY problem and should work either way.