Github ssh -T [email protected]显示了旧的用户名，该用户名找不到

问题描述

git config --list 向我显示了我正确的新用户名(与全局用户名相同)以及正确的ssh推/取路径.但是，如果我键入 ssh -T [email protected] ，我的旧用户名会招呼我，我目前不使用该用户名.

git config --list shows me my correct new username (same for the global one), and the correct ssh push/fetch paths. But if I type ssh -T [email protected], I am greeted by my old username, which I am currently not using.

我什至检查了Windows凭据管理器并删除了所有凭据.效果还是一样的.这个旧名字无处可寻.我想念什么?

I even checked the Windows credential manager and deleted all credentials; still the same effect. This old name is nowhere to be found. What am I missing?

它必须在 ssh-agent 无法获取我的ssh-key的情况下进行某些操作.如果我将ssh-key手动添加到代理中，它将起作用.这引起两个问题:
1)旧用户名来自哪里?
2)为什么不自动添加我的ssh-keys?它们位于$ HOME/.ssh路径中，我添加了在Windows版Git上将ssh-agent自动启动到我的 .bashrc

It has to do something with the ssh-agent being unable to retrieve my ssh-keys. If I manually add the ssh-keys to the agent it works. This arises two questions:
1) Where does the old username come from?
2) Why doesn't it auto-add my ssh-keys? They are in the $HOME/.ssh path, and I added the Auto-launching ssh-agent on Git for Windows script to my .bashrc

EDIT2 :由于Lee的问题，此问题已解决.我可以回答出现的两个问题:
1)旧的用户名来自id_rsa ssh-key.
2)仅当密钥的命名恰好是id_rsa时，脚本才起作用.我误解了文档，以为$ HOME/.ssh/mykey_rsa对于脚本也可以正常工作，但事实并非如此.
因此，如果有人偶然发现了这一点:删除(如果仍然需要，请保存/重命名)id_rsa，然后创建一个新的id_rsa.这样可以解决问题.

Thanks to Lee's question, the issue is solved. I can answer both questions which arised:
1) The old username comes from the id_rsa ssh-key.
2) The script only works if the naming of the key is exactly id_rsa. I missunderstood the documentation, thinking that $HOME/.ssh/mykey_rsa would work as well for the script, but this is not the case.
So, if anyone stumbles upon this: Delete (save it if you still need it/rename) your id_rsa, and create a new id_rsa. This will solve the issue.

推荐答案

使这一点更加清晰和明确:

To make this clearer and more explicit:

1. 请记住，这里至少涉及两台计算机:您的计算机(用于存储各种文件和设置)以及GitHub的计算机.(GitHub使用多台计算机，但它们假装为一台计算机.)

1. Remember, there are at least two computers involved here: yours, where you're storing various files and settings, and GitHub's. (GitHub use multiple machines, but they pretend to be a single computer.)

您的计算机通过Internet调用GitHub，就像打个电话一样.然后，您的计算机会移交某种形式的凭据.他们的计算机检查这些凭据，并确定您是否是您声称的身份.

Your computer calls up the GitHub one over the Internet, as if making a phone call. Your computer then hands over some form of credentials. Their computer inspects these credentials, and decides whether you are who you claim to be.

您交出的凭据取决于拨打电话的方式.如果使用 https://... 进行呼叫，则Git将使用凭据管理器.每个操作系统都有Git可以使用的一套凭据管理器，因此在Windows，MacOS，Linux等上，此过程非常不同.如果您使用 ssh://... 进行呼叫，则尽管仍有OS-出现的特定项目.

The credentials you hand over depend on how you make the call. If you make the call using https://..., Git uses a credential manager. Each OS has its own set of credential managers that Git can use, so the process here is very different on Windows, MacOS, Linux, and so on. If you make the call using ssh://..., all OSes share enough of a common SSH code base that they all proceed in almost the same way at this point, although there are still OS-specific items that come up.

由于您使用的是SSH，因此交出的证书(单个，但请参阅下文)是您的公共ssh密钥(也使用加密，也使用私有密钥，请参见此数字海洋文章.您的ssh密钥存储在特定于操作系统的(可配置)位置.在您的特定情况下，它是 $ HOME/.ssh/id_rsa.pub .末尾没有 .pub 的名称是 private 键，并且这些键成对出现.

Since you're using SSH, the (single, but see below) credential you hand over is your public ssh key (using encryption as well, using your private key—see this Digital Ocean article for instance). Your ssh key is stored in an OS-specific (and configurable) location. In your particular case it was $HOME/.ssh/id_rsa.pub. The name without .pub on the end is the private key, and these keys come in pairs.

当GitHub收到您的密钥时，他们会在一个巨大的表中查找该密钥，并在其中保存每个人都给他们的每个密钥.您的密钥永远不会与其他人的密钥匹配.您给他们提供的密钥有一个用户名与之关联，这是您给他们提供的密钥.由于只有您拥有此密钥(以及随附的私有密钥)，因此GitHub现在可以确保您就是您声称的那个人.

When GitHub receive your key, they look it up in a giant table in which they keep every key that everyone has given them. Your key never matches anyone else's key. The key you gave them has a user name associated with it, back when you gave them that key. Since only you have this key (and the private key that go with it), GitHub can now be sure that you are who you just claimed to be.

索赔完全是通过此公共密钥发生的.如果您不想再声明自己是那个人，请交出不同公钥.您还需要登录Git，并为他们提供新的或更新的公钥.必须在生成公钥/私钥对之后以及使用 ssh 将您的计算机和Git与他们的Git连接到他们的计算机.

The claim happened entirely via this public key. If you don't want to claim to be that person any more, hand over a different public key. You'll also need to log in to Git, and give them the new or updated public key. This must happen after you've generated the public/private key-pair, and before you use ssh to connect your computer and your Git to their computer with their Git.

这里有两件重要的事情要注意，这使原本相对简单的情况变得复杂.同样，简化的图片是:有一个密钥对.您可以将这对密钥对中的公共密钥存储在GitHub上.稍后，您的Git通过 ssh 调用GitHub.您的 ssh 和他们的 sshd 交换一些数据.您的ssh使用密钥对中的两个密钥同时使用加密.他们现在知道您就是您，因为他们可以使用自己的公钥副本来匹配所有内容，只有您拥有 private 密钥，而 you 能够解锁数据.但是您可能想要在 计算机中保留多个密钥对，这会使一切变得复杂.

There are two important things to be aware of here, that complicate this otherwise relatively simple picture. Again, the simplified picture is: There is one key-pair. You store, on GitHub, your public key from this one key-pair. Later, you have your Git call up GitHub via ssh. Your ssh and their sshd exchange some data. Your ssh uses encryption using both keys from your key-pair. They now know that you are you because they can match everything up using their copy of your public key, and only you have the private key that was able to unlock the data. But you might want to keep more than one key-pair in your computer, and that complicates everything.

通用的基本ssh软件可以按顺序尝试各种密钥对.有关(许多和复杂的)详细信息，请参见下面有关多个键的部分.但是，您可以告诉它尝试一个特定的文件，并使用 config 文件(，则您的ssh与您的代理联系，并要求 it 尝试输入密钥.它将一次在主机 H 上尝试这些密钥.如果它们都不起作用，则它仍然具有任何本地存储的文件和/或 IdentityFile 条目中列出的文件.

In the absence of IdentitiesOnly yes, SSH may also offer all the identities—i.e., keys—provided by your SSH Agent. The agent is a helper system that allows you to ship keys from one computer (your most-trusted one) to another, without storing them in files on the less-trusted computer. The way this works looks relatively simple, big-picture-wise: when your ssh contacts some other host H, if you didn't say IdentitiesOnly yes, your ssh contacts your agent and ask it for keys to try. It will try these keys on host H, one at a time. If none of them work, it still has any locally-stored file and/or the ones listed in IdentityFile entries.

但是，细节很复杂.首先，请注意代理本身分为两个部分.(这些不一定是单独的程序，但是通过将每个程序描述为单独的东西来思考系统会更容易.)

The details, however, are complicated. First, note that the agent itself comes in two parts. (These aren't necessarily separate programs, but it's easier to think about the system by describing each as a separate thing.)

• 一个部件在您信任的计算机上运行(密钥存储在文件中).

• One part runs on the machine that you do trust (that has the keys stored in files).

另一部分在您从该受信任计算机通过 ssh 登录的计算机上运行.

The other part runs on the machine that you're logging in to, via ssh, from that trusted machine.

两台机器都启动一个代理.有时，您可能在每台计算机上运行一个以上的代理，而详细信息又因一个操作系统的不同而有所不同-例如，在MacOS上，只需登录即可创建一个代理，然后您的所有终端窗口都可以共享.在任何终端"窗口中，您运行 ssh不受信任的机器并在不受信任的机器上启动新会话，然后 it 也调出一个代理或使用一个已经存在的东西，或者其他任何东西.

Both machines start up an agent. Sometimes you might run more than one agent on each machine, and again the details vary a bit from one OS to another—for instance, on MacOS, simply being logged in creates an agent, which all of your Terminal windows can then share. From any Terminal window, you run ssh less-trusted-machine and start a new session on the less-trusted machine, and it brings up an agent as well, or uses one that you already have, or whatever.

然后您现在在 second 机器上使用Git.不太受信任的计算机的ssh会注意到有一个代理，并要求它提供密钥.该代理与您更受信任的计算机上的代理联系.您更受信任的计算机上的代理将检索密钥并将其移交给或不移交给密钥，这完全取决于两个代理和各种ssh实例正在使用的规则.

You then now use Git on the second machine. The less-trusted machine's ssh notices that there is an agent, and asks it for keys. This agent contacts the agent on your more-trusted machine. The agent on your more-trusted machine retrieves the keys and hands them over, or doesn't, all depending on whatever rules the two agents and various ssh instances are using.

因此，当您使用代理时，不那么受信任的计算机拥有(或有权访问)的密钥集取决于上的代理更多em>-受信任的机器.这就是为什么这张图片很复杂的原因.

Hence, when you're using an agent, the set of keys that the less-trusted machine has (or has access to) depends on what the agent on the more-trusted machine does. So that's why this picture is complicated.

如果您根本不使用代理，或者在命令行解释器中要运行 ssh 或让Git运行 ssh ，则将您完全击败该代理，您运行的ssh或Git运行的ssh只能访问您在 $ HOME/.ssh中的身份(密钥对)/或您放置此类密钥的其他特定于操作系统的位置.当然，它仍然可以访问您放置在其中的所有 密钥.现在，配置中的 IdentitiesOnly yes 行意味着仅使用我在此处列出的文件.非常简单:您列出文件，或者列出每对文件中的一个，并将密钥放入文件中.

If you're not using an agent at all, or if, in the command-line interpreter where you're going to run ssh or have Git run ssh, you defeat the agent entirely, the ssh that you run—or that Git runs—has access only to those identities (key-pairs) that you have in your $HOME/.ssh/ or other OS-specific location where you have put such keys. It still has access to all the keys you have put there, of course. The IdentitiesOnly yes line in your config now means use only the files I listed here. That's pretty straightforward: you list the files—or rather, one of each pair of files, and put the keys in the files.

如果正在使用代理，则您或Git运行的ssh可以访问其他密钥对.在此处添加 IdentitiesOnly 很复杂.它不会阻止您的SSH与代理联系，但是代理返回的每个键都有一个 identity .您可以仅使用与我在 IdentityFile 部分中指定的文件相匹配的身份告诉ssh您正在运行的ssh.这意味着您可以只存储公钥，而不是公钥和私钥对文件.如果您不太信任这台机器(我一直称之为不那么信任的那台机器)，那么可以为您提供一种使用代理将私钥完全关闭的方法.

If you are using an agent, the ssh that you or Git run has access to additional key-pairs. Adding IdentitiesOnly here is complicated. It won't stop your ssh from contact the agent—but each of the keys the agent returns has an identity. You can tell the ssh you're running use only the identities that match the files I specified in the IdentityFile section. What this means is that you can store just the public key, rather than both public and private key-pair files. If you don't trust this machine much—the one I've been calling the less-trusted machine—then that gives you a way to keep your private key off it entirely, using the agent.

最后，无论您在哪台计算机上存储公钥和私钥，您都可以加密它们.现在，您需要输入密码或密码来解锁它们.这可能会很烦人，但是使用代理时，您可以为该代理解锁一次，并信任该代理以确保它们在内存中的安全.(您可以多么信任这个代理人……好吧，这完全是另一个问题！)

Last, on whichever machine you do store both public and private keys, you can encrypt them. You'll now need to enter a password or passphrase to unlock them. This can get annoying, but using an agent, you can unlock them once for the agent, and trust the agent to keep them secure in memory. (How much you can trust this agent ... well, that's another problem entirely!)

实际的解锁和测试您是否通常声称自己是谁，通常在实现ssh的服务器端软件 sshd 内部进行.您的ssh会调用其sshd并交出带有所有加密协议等的密钥.他们使用密钥对的公钥部分在一个锁中尝试使用它，它是否起作用……或者，如果没有起作用，他们可能会为您提供更多尝试.这是可以在服务器上配置的.

The actual unlocking and testing whether you are who you claim to be generally happens inside sshd, the server-side software that implements ssh. Your ssh calls up their sshd and hands over a key, with all the encryption protocols and such. They try it in a lock using the public key part of the key-pair, and it works ... or doesn't—and if it didn't work, they may offer you more tries. This is configurable, on the server.

现在，假设您正在使用代理，并且在代理中存储了五十(50)个不同的密钥.无论您使用哪种计算机，无论您多么信任，您的ssh都会从代理那里获取一个密钥并将其提供给sshd，这是没有用的.您的ssh从代理获取下一个密钥，然后尝试该密钥，这也不是正确的密钥.就像您正在翻阅钥匙圈上的50个按键，甚至没有看着每个按键，而是试图将其锁定.一段时间后，服务器上的sshd会反复出现错误:这似乎是您在尝试闯入.

Now, suppose you are using an agent and have fifty (50) different keys stored in your agent. Your ssh, on whichever computer you're on—however trusted it is—gets one key from the agent and gives it to an sshd, and it's no good. Your ssh gets the next key from the agent, and tries that one, and it's not the right key either. It's like you're fumbling through 50 keys on a key ring, not even looking at each key, and trying it in a lock. After a while, the sshd on the server gets alarmed by the repeated failures: it looks like you're trying to break in.

一台服务器与另一台服务器之间允许的实际尝试次数有所不同，因为它是可配置的.但是，如果您确实有很多个键，则尝试使用 right 键(仅或第一个)是个好主意.为此，您需要使用 IdentitiesOnly是行，是否使用代理:

The actual number of tries allowed varies from one server to another, because it's configurable. But if you do have a lot of keys, it's a good idea to try the right key (only, or first). To do that, you'll want to use the IdentitiesOnly yes line, whether or not you use an agent:

• 如果不使用代理，则 IdentitiesOnly是表示仅使用此处每个 IdentityFile 配置条目中列出的公钥/私钥对.因此，您列出了正确的密钥，而ssh使用了正确的密钥，并且它适合锁，并且它们的sshd喜欢您，一切都很好.

• If you do not use an agent, IdentitiesOnly yes means only use the public/private key pairs listed in each IdentityFile configuration entry here. So you list the right one, and your ssh uses the right one, and it fits the lock and their sshd likes you, and all is good.

如果您确实使用了代理，则 IdentitiesOnly是表示使用与 IdentityFile 中列出的公钥相匹配的代理密钥.配置条目或此处的条目.因此，您列出了正确的列表，而ssh使用了正确的列表，并且像以前一样，一切都很好.

If you do use an agent, IdentitiesOnly yes means use the agent's key(s) that matches the public-key listed in the IdentityFile configuration entry or entries here. So you list the right one, and your ssh uses the right one, and as before, all is good.

如果您使用代理，但是只有几个键(取决于所调用服务器上的sshd配置，仅一个或两个，甚至最多六个左右)，就不需要 IdentitiesOnly 和 IdentityFile 行.但是只要您正确，他们就不会受伤.

If you use an agent, but have only a few keys—just one or two or maybe even up to about six or so, depending on the sshd configurations at the servers you call up—you don't need the IdentitiesOnly yes and IdentityFile lines. But they won't hurt, as long as you get them right.

• 您可以(实际上必须)将密钥对文件存储在最受信任的计算机上的某个位置.您也可以加密，以便您必须输入密码或密码来解锁它们，尽管这可能会很烦人.代理商可以提供帮助.您可能(可能需要)使用 ssh-add 将密钥加载到该代理中.

• You can (and in fact must) store the key-pair files somewhere, on a mostly-trusted computer. You can encrypt these as well so that you must type in a password or passphrase to unlock them, although this can get annoying. An agent can help. You may (probably will) need to load keys into that agent using ssh-add.

从一台计算机切换到另一台计算机时，可以将代理转发到下一台计算机上的新代理.链中的第二台及以后的任何计算机都需要密钥对的 public 密钥，以确认您是您自己，但是如果您已设置代理转发，则它们不需要专用键.

When you ssh from one computer to another, you can have your agent forwarded, to a new agent on the next computer. The second and any subsequent computers in the chain need the public key of the key-pair, to verify that you are you, but if you've set up agent forwarding, they don't need the private key.

此信任链中的每台计算机(即您从更受信任的计算机上 ssh 进入)都将在启动ssh会话时获取最初发送的加密数据.他们使用已存储的公钥，您已经以某种方式(您喜欢/可以的方式)将其存储在不受信任的计算机上，以查看您是否知道私有钥匙.如果这样做，您实际上必须是您自己.

Each computer in this chain of trust—that you ssh into from a more-trusted computer—takes the encrypted data you send initially, as you start up the ssh session. They use a stored public key, that you have somehow (any way you like / can), already stored onto the less-trusted computer, to see if you know the private key. If you do, you must actually be you.

除了他们幻想自己的 sshd 之外，GitHub确实没有什么不同:它只是您登录"(如[email protected] ).他们采用您提供给他们的密钥并进行查找-但是，不仅仅是拥有 you 的一个密钥，他们还有一个每个GitHub上存在的帐户的密钥.他们尝试您提供给他们的钥匙，看看它是否可以在Alice的锁中起作用.不?一定不能是爱丽丝；试试鲍勃的锁.不?尝试Carol，然后一直进行下去，直到它可以解锁Fred，Rita或Zack.当他们到达起作用的存储的 .pub 密钥时，那肯定是您您的身份.

Except for the fact that they've fancied up their sshd, GitHub is really no different: it's just a less-trusted computer that you "log into" (as [email protected]). They take the key you give them and look it up—but instead of just having one key for you, they have one key for every account that exists on GitHub. They try the key you give them and see if it works in the lock for Alice. Nope? Must not be Alice; try it in the lock for Bob. No? Try Carol—and so on down the line, until maybe it unlocks Fred, or Rita, or Zack. When they get to the stored .pub key that works, well, that must be who you are.

在shell会话中，您将看到一个环境变量 SSH_AUTH_SOCK ，其中包含您使用 ssh 的路径名在计算机与代理联系上运行 .如果您覆盖或取消设置环境变量，则会使代理失败.

In a shell session, you'll see an environment variable, SSH_AUTH_SOCK, that holds the path name by which an ssh you run on that machine contacts the agent. If you override or unset the environment variable, this defeats the agent.

要查看您是否有活动的代理，如果有，请使用 ssh-add -l .

To see if you have an agent active, and if so, what keys it has access to, use ssh-add -l.

像这样一次线性地通过成千上万个身份尝试一个身份太慢了，因此GitHub必须在内部使用不同的策略.但是效果是一样的:您通过ssh到他们的sshd，通过公用/专用密钥对和加密为他们提供了一个标识位字符串.他们使用收集到的每个人的授权密钥，并在该堆中找到一个唯一的某人，无论找到的人是谁，都是您.如果找不到任何人，他们将拒绝密钥，并且您的ssh可以继续提供另一个密钥，最高可以达到在他们的 sshd中设置的上限.

Trying one identity at a time like this, linearly through thousands or millions of identities, is much too slow, so GitHub must necessarily use a different strategy internally. But the effect is the same: you gave them an identity bit-string, via your public/private key-pair and encryption, from your ssh to their sshd. They use the collected authorized keys for everyone and find a unique someone in that pile, and whoever they found, that's you. If they don't find anyone, they reject the key, and your ssh can go on to offer another key, up to whatever limit they have set in their sshd.

这篇关于Github ssh -T [email protected]显示了旧的用户名，该用户名找不到的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！