The fundamental problem is that I am never seeing a prompt to enter in my SSH-Key password, SSH-Agent or no. As such, it's acting like I entered the wrong password and defaulting to pretending I have no keys.
This is happening on multiple computers. I set up my ssh keys awhile ago, and everything is great, but every so often I will do a git push (usually after restarting my computer) and I will get asked for my git origin server's password RATHER than my ssh key's password. Since my origin server does not HAVE a password, this leaves me unable to push changes.
Sometimes it resolves itself after restarting, sometimes not. Usually I do a lot of flailing guesses and one of them ends up fixing the problem, but I can't currently remember which ones work and which don't.
What is the CORRECT way to go about fixing this? What is the actual problem? Is my SSH Key locked? Is some windows process not starting correctly? Is a Path variable being eaten? I don't know a lot about windows (usually I develop on linux), so I'm extra at a loss here.
Edit: The first answer mentions ssh-agent. Some googling got me to here:
https://help.github.com/articles/working-with-ssh-key-passphrases/#platform-windows
Which explains how to set up ssh-agent to autostart and know about your keys in windows. (I didn't even know you could use bash profiles in windows).
This did not help.
My git bash now says "Identity added: /c/Users/{{ME}}/.ssh/id_rsa" It does NOT ask me for my key password, and I still cannot push to my origin server (it asks for a server password, still).
I can confirm that my ssh key does live in the place the agent is looking. I can also confirm that the key is added: ssh-add -l shows a single key, from the location my key is stored.
Edit: Setting GIT_SSH as an environment variable pointing at the executable for ssh does nothing either, but it was a long shot anyways.
Edit: ssh [email protected] outputs:
$ ssh -v [email protected] OpenSSH_6.6.1, OpenSSL 1.0.1i 6 Aug 2014 debug1: Reading configuration data /c/Users/eschjen/.ssh/config debug1: /c/Users/eschjen/.ssh/config line 1: Applying options for git.myhost .lan debug1: Connecting to git.myhost.lan [10.116.22.40] port 22. debug1: Connection established. debug1: identity file /c/Users/eschjen/.ssh/id_rsa type 1 debug1: identity file /c/Users/eschjen/.ssh/id_rsa-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.6.1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3 debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Server host key: RSA ae:81:77:0d:1c:8e:6a:aa:a8:69:36:1b:e4:ca:33:ee debug1: Host 'git.myhost.lan' is known and matches the RSA host key. debug1: Found key in /c/Users/eschjen/.ssh/known_hosts:1 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mi c,password debug1: Next authentication method: publickey debug1: Offering RSA public key: /c/Users/eschjen/.ssh/id_rsa debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mi c,password debug1: Next authentication method: password [email protected]'s password: The output screen helped me take the tack that the ssh key was being used, but rejected by the server. I found that the ssh key my server knows about does not match the ssh key my machine has, somehow, despite everything working fine less than a month ago. I re-added the ssh key I have, and was able to push my changes.
Anybody have any idea how the ssh key would be re-generated (I'm fairly sure I didn't do it explicitly) during all of this?
