我真的對我的 bitbucket 的行為感到困惑：

1. 我有一個名為 的專案Prototype，其中有多個存盤庫；

2. 我能夠將新提交推送到名為Tiger; 我假設我已經在 bitbucket 的“個人設定/SSH 密鑰”中設定了筆記本電腦的 ssh 密鑰，因為Tiger如果我沒有這樣做，我將無法推送提交。

3. 還有另一個名為 的 repo Cat，我剛剛發現我無法向它推送新的提交。這真的讓我很困惑，因為我在同一臺筆記本電腦上；

4. 所以我檢查了我的 bitbucket 的“個人設定/SSH 密鑰”，然后 BOOM！我的筆記本電腦沒有 ssh 密鑰存盤在那里！

那么我如何能夠首先推動Tiger？我可能弄錯了......但我記得我已經將筆記本電腦的 ssh 密鑰存盤在 bitbucket 中。

5. 然后我繼續嘗試將筆記本電腦的 ssh 密鑰保存到 bitbucket，但它說： Someone has already added that SSH key.

到底他媽發生了什么？

有任何想法嗎？

uj5u.com熱心網友回復：

TL;博士

Fredrik 的評論有關鍵的見解（如果你能原諒這里的措辭）：

您正在嘗試將相同的密鑰添加到兩個不同的 bitbucket 帳戶

這只是 ssh 認證的問題，但對于 ssh 認證來說卻是個大問題。您必須為每個 Bitbucket 帳戶使用唯一的公鑰。

龍：怎么了

Git 本身不包含身份驗證。為了做分布式的事情，你的 Git 軟體必須連接到其他一些 Git 軟體。這兩個軟體版本不必相同——事實上，有些服務器可能根本不使用 (C) Git——只要它們都使用 Git協議，但協議沒有身份驗證。它只是假設在使用協議時，服務器和客戶端已經完全相互信任。因此，在主機系統相信你是你聲稱的人之前，你必須以某種方式證明你是。這是身份驗證程序。

通常，身份驗證包括建立某種用戶身份。每個 Web 托管站點都有點不同（出于 $reasons 的原因，有時與實際美元有關，有時$reasons只是一個元變數），但是有兩種通用和常見的方法可以對任何大型 Git 托管站點進行身份驗證：

• http(s)（現在主要是 https-only，因為普通的 http 非常不安全），或者
• SSH。

https 身份驗證具有最大的可變性，因為有許多 https實作，并且每個都有自己的身份和授權技術，因此我們至少可以說它是一種。但是，Bitbucket 和 GitHub 現在都使用基于令牌的身份驗證，而不是基于密碼的身份驗證。令牌和密碼之間的區別本質上是，令牌是結構化的密碼，具有 (hidden-from-the-user) 結構包含額外資訊。一個是讓網站生成令牌（通常使用密碼，也許還有一些用于雙因素身份驗證的第二因素）。然后一個人指示一個人的 Git 提供用戶名和令牌作為密碼。這對在您訪問托管站點時對您進行身份驗證。這里的用戶名是你的身份，密碼或令牌是你的身份證明（所以要小心！）。

要在 Git 中使用此方法，請使用以 . 開頭的 URL https://。這些采用形式（盡管您可以將密碼/令牌推入此處，或省略部分，但通常最簡單的方法是包含用戶并省略密碼，因此只需通過某些憑據系統管理密碼）。https://user@host/path/passed/to/hostuser

ssh 身份驗證更加統一，這可能是因為 ssh 實作較少，并且大多數都將其歷史追溯到一個共同的起點。要在 Git 中使用 ssh 身份驗證，請使用以 開頭ssh://或格式為 的 URL ，例如. ssh 系統使用公鑰加密；這里不涉及密碼，至少在這一點上。user@host:path[email protected]:my/repo.git

您的 Git 軟體不會自行進行任何身份驗證，但它可以使用憑證助手。它僅用于 https 身份驗證。這是高度可配置的，并且有很多系統依賴項。這也不是最初的問題是關于什么的，所以這就是我們在這里要說的全部內容。

對 Git 和大型托管站點使用 ssh 身份驗證

當您使用 ssh 進行身份驗證時，會涉及到一個用戶名，它就在 URL:或. 部分（如果使用這種形式）和 at-sign `@ 和冒號（如果使用這種形式）是將出現在 URL 中的文字字符。ssh://user@host/pathuser@host:pathssh://

所有大型 Git 服務器都要求您提供該user部分作為文字字串git。也就是說，他們不會以您自己的身份驗證您，而是以git偽用戶身份驗證您。這有很多技術原因，但它們都歸結為“那樣更容易，現在是慣例”。由于您將聲稱自己是這個git偽用戶，而不是您的真實身份，因此主機將需要以其他方式弄清楚您的真實身份。大型 Git 服務器這樣做的方式是作弊。

如果我們查看公鑰密碼學，我們會發現它的作業原理是讓您（或您的 Git 軟體，或者在這種特殊情況下，ssh 程式——Git在 這里運行，ssh因為 Git 本身不包含 ssh 代碼）提供給服務器公鑰：一長串看起來隨機的字母和數字以及可能代表某種加密密鑰的其他字符。公鑰之所以這樣稱呼，是因為它不是秘密！你可以把它展示給任何人，盡管沒有充分的理由去抱怨它。

除了這個公鑰，不管它是什么，還有一個配對的私鑰，你應該保密（小心保護它，就像密碼一樣）。只要有公鑰，任何人都可以輕松加密任何資料；私鑰的持有者可以使用私鑰輕松解密相同的資料，但沒有私鑰的人不能。¹ 因此，當使用 ssh 時，您連接到服務器（在本例中為 Bitbucket）并聲稱自己是用戶git并向他們發送公鑰。他們使用公鑰加密一個隨機選擇的字串，您使用您的私鑰對其進行解密并將其發回，他們會看到您實際上擁有私鑰。

但是：他們怎么知道你是誰？ 您聲稱自己是git偽用戶。這就是作弊的來源：每個公鑰/私鑰對都有一個唯一的公鑰。² 因此，在某個時間點（早在您使用 ssh 連接到托管服務器之前），您必須使用https（以及用戶名和密碼，可能還有 2FA）連接到托管服務器，并將您計劃的公鑰上傳到托管服務器稍后與您的 ssh 連接一起使用。

此時，托管服務器（在本例中為 Bitbucket）在他們擁有的所有公鑰的大表或資料庫中查找。如果你剛剛給他們的公鑰已經在 table 中，他們會給你你看到的錯誤：

Someone has already added that SSH key.

那個人可能是你。事實上，假設公鑰的唯一性，那一定是你！他們沒有告訴你是誰，他們只是告訴你現在不能添加這個，因為我，bitbucket，已經有了它。（如果你想知道他們認為這個特定的公鑰代表誰，你只需要運行ssh -T [email protected]：你也有私鑰，你的 ssh 將使用它來解密他們發送的內容，你將成功登錄，并且他們會告訴你他們認為你是誰。）

假設密鑰不在他們的大表/資料庫中，他們會添加它，以及您用來使用 https 登錄他們的站點的用戶名。現在托管服務器知道，如果將來有人——任何人！——出現并提供該公鑰，則該“某人”自稱是你。如果那個人也可以解密他們作為挑戰提供的隨機字串，那么這個人也有私鑰，因此就是你。

¹不是，也就是說，沒有像足夠強大的量子計算機這樣的神奇東西。 正如鏈接文章中所討論的， “后量子”密碼學是防御這種未來威脅的一種嘗試。

²這在任何技術意義上都不能保證，但公鑰中包含足夠多的額外資料和其他垃圾，在任何實際意義上，它始終是唯一的。Git 本身對物件哈希 ID 也有同樣的問題：它們只是在實踐中是唯一的，而不是在理論上。 在理論上，理論和實踐是相同的，但在實踐中它們不是。——本杰明·布魯斯特，很有可能

你的情況發生了什么

這是不可能確定的。也許您對一個存盤庫使用 https 身份驗證，而對另一個存盤庫使用 ssh 身份驗證。

然而，你現在知道你可以跑去ssh -T [email protected]看看他們認為你是誰。這是基于您提供給他們的公鑰。如果您需要在Bitbucket 上擁有多個帳戶，則需要仔細控制您提供的公鑰。

請注意，ssh 可以使用代理來存盤密鑰對：這使您可以避免將密鑰對直接存盤在您正在使用的計算機上（例如，如果您正在通過共享的中間作業機器，您可能想要將您的筆記本電腦端密鑰保留在非共享筆記本電腦上，并使用代理僅在需要時將它們短暫地傳遞給共享機器）。但是，當您使用代理時，您會失去對在 ssh 協商中的哪個時間點提供哪些密鑰的一些控制。該.ssh/config檔案允許您指定只應給出一些特定的密鑰。您也可以使用這種機制來說明您的 ssh 應該提供偽用戶git用戶名：參見，例如，Bitbucket ssh 公鑰被拒絕，但他們的 ssh 測驗連接沒有問題（這個問題可以追溯到 Bitbucket 在過渡期間仍然是 Mercurial 服務器的時代）。

標籤：混帐 SSH 比特桶

上一篇：成功拉取請求后開發分支X在主分支后面提交

下一篇：Git鉤子跨平臺的條件shebang