Windows真的只是自发地为git生成了我的ssh密钥吗? [英] Did Windows really just spontaneously regenerate my ssh key for git?

问题描述

多年以来，每次我(或公司中的其他任何人)每次尝试在Windows上使用git时，一切都可以正常工作一会儿，直到突然之间好像它不再知道什么是ssh密钥一样.它将不再提示我输入密码，而是要求我输入git服务器的密码.

For years, every time I (or anyone else in my company, it seems) tries to use git on windows, everything will work fine for awhile, until suddenly it acts like it doesn't know what an ssh key is anymore. It'll stop prompting me for it's password, and instead ask me for the git server's password instead.

ssh -v向我指出了正确的方向，即Windows知道我的ssh密钥，但是它似乎未被我的服务器接受.

ssh -v pointed me in the right direction, namely that windows DOES know about my ssh key, but it doesn't seem to be accepted by my server.

    $ ssh -v [e-mail]
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
[e-mail]'s password:

看我的服务器，我可以看到我的旧的Windows公共ssh密钥已上传，但是它不再与我的计算机上的密钥匹配.像上一台新计算机一样上载新密钥可以完全解决问题.

Looking at my server, I could see that my old windows public ssh key is uploaded, but that it no longer matches the one on my machine. Uploading the new key as if it were a new computer fixes the problem completely.

这是Windows偶尔会做的事情吗?为什么我的钥匙突然间无效?我大概是不到一年前生成的.

Is this something that windows just does occasionally? Why on earth would my key suddenly be invalid? I generated it probably less than a year ago.

推荐答案

Windows不会自行重置ssh密钥.

Windows does not reset the ssh keys by itself.

但是id_rsa/id_rsa.pub是默认 ssh私钥和公钥的文件名.
这意味着，如果任何其他应用生成了一组新的密钥，则这些密钥将被覆盖.

But id_rsa/id_rsa.pub are the default ssh private and public key filenames.
That means if any other app generates a new set of keys, said keys will be overwritten.

为了提高ssh设置的健壮性，可能的解决方法是:

A possible workaround, in order to improve the robustness of the ssh setup, is to:

• 重命名%HOME%\.ssh中的密钥:
• 添加%HOME%\.ssh\config私钥的完整路径

• rename your keys in in %HOME%\.ssh:
• add in %HOME%\.ssh\config the full path of the private key

类似的东西:

Host git.myhost.lan
  HostName git.myhost.lan
  User git
  IdentityFile C/Users/<yourLogin>/.ssh/git.myhost.lan

然后尝试ssh -Tv git.myhost.lan(无需git@)

这篇关于Windows真的只是自发地为git生成了我的ssh密钥吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！