Как да управлявате множество GitHub акаунти на една машина със SSH ключове

Необходимостта от управление на множество GitHub акаунти на една и съща машина се появява в даден момент от времето за повечето разработчици. Всеки път, когато ми се случи да сменя своя Mac или трябва да Git push с нов работен акаунт, в крайна сметка сърфирам за това как да направя нещо, което съм правил над половин дузина пъти.

Мързелът ми да не документирам процеса и невъзможността да запомня стъпките ме кара да прекарам прилично време, за да взема парчета от цялата мрежа и след това някак да го накарам да работи.

Сигурен съм, че има много от вас, които са били там, направили са това и много повече от вас, които само чакат следващия път, когато се случи същото (включително и аз!). Това начинание има за цел да ни помогне.

1. Генериране на SSH ключове

Преди да генерираме SSH ключ, можем да проверим дали имаме съществуващи SSH ключове: ls -al ~/.sshТова ще изброи всички съществуващи двойки публични и частни ключове, ако има такива.

Ако ~/.ssh/id_rsaе наличен, можем да го използваме повторно или в противен случай първо да генерираме ключ към подразбирането, ~/.ssh/id_rsaкато стартираме:

ssh-keygen -t rsa

Когато бъдете помолени за местоположението за запазване на ключовете, приемете местоположението по подразбиране, като натиснете enter. Частен ключ и публичен ключ ~/.ssh/id_rsa.pubще бъдат създадени на местоположението по подразбиране ssh ~/.ssh/.

Нека използваме тази двойка ключове по подразбиране за личния си акаунт.

За работните акаунти ще създадем различни SSH ключове. Кодът по-долу ще генерира SSH ключовете и запазва публичния ключ с етикет [email protected]_mail.com” в~/.ssh/id_rsa_work_user1.pub

$ ssh-keygen -t rsa -C "[email protected]_mail.com" -f "id_rsa_work_user1" 

Създадени са два различни ключа:

~/.ssh/id_rsa ~/.ssh/id_rsa_work_user1

2. Добавяне на новия SSH ключ към съответния акаунт в GitHub

Вече имаме готови публични ключове на SSH и ще помолим нашите акаунти в GitHub да се доверят на ключовете, които сме създали. Това е, за да се отървете от необходимостта от въвеждане на потребителско име и парола всеки път, когато натискате Git.

Копирайте публичния ключ pbcopy < ~/.ssh/id_rsa.и след това влезте в личния си акаунт в GitHub:

  1. Отидете на Settings
  2. Изберете SSH and GPG keysот менюто вляво.
  3. Кликнете върху New SSH key, предоставете подходящо заглавие и поставете ключа в полето по-долу
  4. Щракнете Add key- и готово!
За служебните акаунти използвайте съответните публични ключове ( pbcopy < ~/.ssh/id_rsa_work_user1.pub) и повторете горните стъпки във вашите работни акаунти в GitHub.

3. Регистриране на новите SSH ключове с ssh-агент

За да използваме ключовете, трябва да ги регистрираме в ssh-агента на нашата машина. Уверете се, че ssh-agent работи с помощта на командата eval "$(ssh-agent -s)".

Добавете ключовете към ssh-агента по следния начин:

ssh-add ~/.ssh/id_rsa ssh-add ~/.ssh/id_rsa_work_user1

Накарайте ssh-агентът да използва съответните SSH ключове за различните SSH хостове.

Това е решаващата част и ние имаме два различни подхода:

Използване на SSH конфигурационен файл (Стъпка 4) и наличието на само един активен SSH ключ в ssh-агента наведнъж (Стъпка 5).

4. Създаване на SSH конфигурационен файл

Тук всъщност добавяме правилата за конфигуриране на SSH за различни хостове, като посочваме кой файл за идентичност да използвам за кой домейн.

Конфигурационният файл на SSH ще бъде достъпен на ~ / .ssh / config .Редактирайте го, ако съществува, или иначе можем просто да го създадем.

$ cd ~/.ssh/ $ touch config // Creates the file if not exists $ code config // Opens the file in VS code, use any editor

Направете конфигурационни записи за съответните акаунти в GitHub, подобни на тези по-долу във вашия ~/.ssh/configфайл:

# Personal account, - the default config Host github.com HostName github.com User git IdentityFile ~/.ssh/id_rsa # Work account-1 Host github.com-work_user1 HostName github.com User git IdentityFile ~/.ssh/id_rsa_work_user1

Work_user1 ” е потребителският идентификатор на GitHub за работния акаунт.

G ithub.com- work_user1 “ е обозначение, използвано за разграничаване на множество Git акаунти. Можете също да използвате нотация „ work_user1.g ithub.com“ . Уверете се, че сте съгласни с това каква нотация на хост използвате. Това е от значение, когато клонирате хранилище или когато задавате отдалечен произход за локално хранилище

Горната конфигурация иска от ssh-agent да:

  • Използвайте id_rsa като ключзавсеки Git URL, който използва @ github.com
  • Използвайте ключа id_rsa_work_user1 за всеки Git URL, който използва @ github.com-work_user1

5. Един активен SSH ключ в ssh-агента наведнъж

Този подход не изисква правилата за конфигуриране на SSH. По-скоро ние ръчно гарантираме, че ssh-агентът има само съответния ключ, прикрепен по време на всяка операция на Git.

ssh-add -lще изброи всички SSH ключове, прикрепени към ssh-агента. Премахнете всички от тях и добавете един ключ, който ще използвате.

Ако сте на личен акаунт в Git, който сте на път да натиснете:

$ ssh-add -D //removes all ssh entries from the ssh-agent $ ssh-add ~/.ssh/id_rsa // Adds the relevant ssh key

Сега ssh-agentът има картографиран ключ с личния акаунт в GitHub и можем да направим Git тласък към личното хранилище.

За да натиснете към вашия работен GitHub акаунт-1, променете SSH ключа, картографиран със ssh-агент, като премахнете съществуващия ключ и добавите SSH ключа, картографиран с работния акаунт в GitHub.

$ ssh-add -D $ ssh-add ~/.ssh/id_rsa_work_user1

Понастоящем ssh-агентът има картографиран ключ с работния акаунт в Github и можете да направите Git тласък към работното хранилище. Това обаче изисква малко ръчни усилия.

Задаване на git отдалечен URL за локалните хранилища

След като имаме клонирани / създадени локални хранилища на Git, уверете се, че потребителското име и имейл на Git config са точно това, което искате. GitHub идентифицира автора на всеки ангажимент от имейл идентификатора, приложен с описанието на ангажимента.

За да изброите името на конфигурацията и имейла в локалната Git директория, направете git config user.nameи git config user.email. Ако не е намерен, актуализирайте съответно.

git config user.name "User 1" // Updates git config user name git config user.email "[email protected]"

6. Докато клонирате хранилища

Забележка: стъпка 7 ще помогне, ако хранилището вече е налично на локално ниво.

Сега, когато конфигурациите са налице, можем да продължим и да клонираме съответните хранилища. При клонирането отбележете, че използваме имената на хостове, които използвахме в конфигурацията на SSH.

Хранилищата могат да бъдат клонирани с помощта на командата за клониране, която Git предоставя:

git clone [email protected]:personal_account_name/repo_name.git

Работното хранилище ще изисква да се направи промяна с тази команда:

git clone [email protected]_user1:work_user1/repo_name.git

Тази промяна се извършва в зависимост от името на хоста, дефинирано в SSH конфигурацията. Низът между @ и: трябва да съвпада с това, което сме дали в конфигурационния файл на SSH.

7. За локално съществуващи хранилища

Ако хранилището вече е клонирано:

Избройте Git дистанционното на хранилището, git remote -v

Проверете дали URL съответства на нашия GitHub хост, който ще се използва, или пък актуализирайте отдалечения URL адрес.

git remote set-url origin [email protected]_user1:worker_user1/repo_name.git

Уверете се, че низът между @ и: съответства на хоста, който сме дали в SSH конфигурацията.

Ако създавате ново хранилище на локално:

Initialize Git in the project folder git init.

Create the new repository in the GitHub account and then add it as the Git remote to the local repository.

git remote add origin [email protected]_user1:work_user1/repo_name.git 

Ensure the string between @ and : matches the Host we have given in the SSH config.

Push the initial commit to the GitHub repository:

git add . git commit -m "Initial commit" git push -u origin master

We are done!

Adding or updating the Git remote of the local Git directory with the proper host will take care of selecting the correct SSH key to verify our identity with GitHub. With all the above in place, our git operations should work seamlessly.