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

Безопасно е да се каже, че повечето разработчици в уеб сферата в даден момент са се сблъсквали със SSH. SSH е един от най-използваните протоколи за безопасен обмен на данни. Използвате SSH за свързване с отдалечени сървъри, което също включва управление на вашия код с помощта на Git и синхронизиране с отдалечени хранилища.

Въпреки че се счита за добра практика да имате по една двойка частно-публични ключове на устройство, понякога трябва да използвате множество ключове и / или имате неортодоксални имена на ключове.

Може да използвате една двойка SSH ключове за работа по вътрешни проекти на вашата компания, но може да използвате различен ключ за достъп до някои сървъри на корпоративен клиент. Може дори да използвате различен ключ за достъп до вашия собствен частен сървър.

Управлението на SSH ключове може да стане тромаво веднага щом трябва да използвате втори ключ. Надявам се тази статия да бъде в помощ на всеки, който има проблеми с управлението на SSH ключове.

Предполагам, че читателят има основни познания за Git и SSH. Повечето примери в цялата статия ще използват Git. Разбира се, всичко това ще се отнася за всяка друга SSH комуникация. Като се има предвид, има включени някои специфични за Git трикове.

Вземете каишка, ето!

Справяне с един SSH ключ

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

Имате един частен ключ, съхраняван ~/.ssh/id_rsaсъс съответния публичен ключ ~/.ssh/id_rsa.pub.

Нека си представим, че искате да натиснете / издърпате промените на кода към / от отдалечен Git сървър - да речем GitHub, защо не. За да направите това, първо трябва да добавите публичния си ключ към GitHub.

Няма да премина през тази стъпка, трябва да е достатъчно лесно, за да разбера как да го направя. Също така предположих, че се казвате Стив и работите по свръхсекретен проект, който използва Raspberry Pies, за да подуши мрежовия трафик.

За да започнете работата си, трябва да клонирате git хранилище, използвайки SSH:

git clone [email protected]:steve/raspberry-spy.git

В този момент GitHub ще бъде като: „Йо, това е частно хранилище! Трябва да шифроваме трафика, използвайки този публичен ключ, който имам тук, и вашия частен ключ. "

Добавили сте публичния ключ към вашия профил в GitHub, но SSH трябва по някакъв начин да разбере къде се намира съответният ви частен ключ.

Тъй като нямаме представа кой частен ключ трябва да се използва при SSH-влизане [email protected], SSH клиентът се опитва да намери ключ в местоположение по подразбиране, което е ~/.ssh/id_rsa- това е най-доброто му предположение. Ако на това място няма файл, ще получите грешка:

Cloning into 'raspberry-spy'... Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.

Ако имате някакъв частен ключ се съхранява в досие ~/.ssh/id_rsa, SSH клиент ще използва този частен ключ за комуникация криптиране. Ако този ключ е с парола (както трябва да бъде), ще бъдете подканени да въведете парола по следния начин:

Enter passphrase for key '/Users/steve/.ssh/id_rsa':

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

Но какво, ако сте нарекли своя ключ по различен начин (напр. ~/.ssh/_id_rsa)? SSH клиентът няма да може да определи къде се съхранява частният ключ. Ще получите същата Permission denied ...грешка като преди.

Ако искате да използвате частен ключ, който сте посочили по различен начин, трябва да го добавите ръчно:

ssh-add ~/.ssh/_id_rsa

След въвеждане на паролата можете да проверите дали ключът е добавен към ssh-agent(SSH клиент) чрез изпълнение ssh-add -l. Тази команда ще изброи всички ключове, които в момента са достъпни за SSH клиента.

Ако опитате да клонирате хранилището сега, то ще бъде успешно.

Дотук добре?

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

Първо, ако рестартирате компютъра си, ssh-agentще се рестартира и ще трябва да добавите вашите ключове без име по подразбиране, като използвате ssh-addвсичко отначало, като въведете пароли и всички онези досадни неща.

Можем ли да автоматизираме добавянето на ключове или по някакъв начин да посочим кой ключ да използваме при достъп до определени сървъри?

Можем ли по някакъв начин да запазваме пароли, за да не се налага да ги въвеждаме всеки път? Ако само имаше нещо като ключодържател за запазване на защитени с парола SSH ключове?.

Бъдете сигурни, че има отговори на всички тези въпроси.

Влез, SSH config

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

Управление на SSH ключове с специално име

Първото нещо, което ще решим с помощта на този configфайл, е да избягваме да добавяме потребителски име SSH ключове, използвайки ssh-add. Ако приемем, че вашият SSH ключ е именуван ~/.ssh/_id_rsa, добавете следното към configфайла:

Host github.com HostName github.com User git IdentityFile ~/.ssh/_id_rsa IdentitiesOnly yes

Сега се уверете, че ~/.ssh/_id_rsaне е в ssh-agentизпълнението ssh-add -D. Тази команда ще премахне всички ключове от активната в момента ssh-agentсесия. Сесията се нулира всеки път, когато излезете или рестартирате (или ако убиете ssh-agentпроцеса ръчно). Можем да „симулираме“ рестартиране, като изпълним споменатата команда.

Ако опитате да клонирате вашето хранилище на GitHub сега, то ще бъде същото, както ако добавихме ключа ръчно (както направихме преди). Ще бъдете помолени за парола:

git clone [email protected]:steve/raspberry-spy.git Cloning into 'raspberry-spy'... Enter passphrase for key '/Users/steve/.ssh/_id_rsa':

Ще забележите, че ключът, за чиято парола сме подканени, е същият ключ, който посочихме в нашия configфайл. След въвеждане на правилната парола за SSH ключ, хранилището ще бъде успешно клонирано.

Забележка: ако след успешно клониране опитате git pull, ще бъдете подканени да въведете парола отново. Ще разрешим това по-късно.

Важно е, че Host github.comот configи github.comот URI [email protected]:steve/raspberry-spy.gitсъвпадат. Можете също да промените configда бъдете Host mygithubи да клонирате с помощта на URI [email protected]:steve/raspberry-spy.git.

This opens the floodgates. As you are reding this, your mind is racing and thinking about how all your troubles with SSH keys are over. Here are some useful configuration examples:

Host bitbucket-corporate HostName bitbucket.org User git IdentityFile ~/.ssh/id_rsa_corp IdentitiesOnly yes

Now you can use git clone [email protected]:company/project.git

Host bitbucket-personal HostName bitbucket.org User git IdentityFile ~/.ssh/id_rsa_personal IdentitiesOnly yes

Now you can use git clone [email protected]:steve/other-pi-project.git

Host myserver HostName ssh.steve.com Port 1111 IdentityFile ~/.ssh/id_rsa_personal IdentitiesOnly yes User steve IdentitiesOnly yes

Now you can SSH into your server using ssh myserver. How cool is that? You do not need to enter port and username manually every time you execute ssh command.

Bonus: Per-repository settings

You can also define which specific key should be used for certain repository, overriding anything in SSH config. Specific SSH command can be defined by setting sshCommand under core in /.git/config. Example:

[core] sshCommand = ssh -i ~/.ssh/id_rsa_corp

This is possible with git 2.10 or later. You can also use this command to avoid editing the file manually:

git config core.sshCommand 'ssh -i ~/.ssh/id_rsa_corp'

Password managemet

Last piece of the puzzle is managing passwords. We want to avoid having to enter password every time when SSH connection is initiating. To do so, we can utilize keychain management software that comes with MacOS and various Linux distributions.

Start by adding your key to the keychain by passing -K option to the ssh-add command:

ssh-add -K ~/.ssh/id_rsa_whatever

Now you can see your SSH key in the keychain. On MacOS it looks something like this:

Keychain Access

If you remove the keys from ssh-agent via ssh-add -D (this will happen when you restart your computer, as mentioned before) and try SSH-ing, you will be prompted for password again. Why? We just added the the key to the keychain. If you check Keychain Access again, you will notice that the key you added using ssh-add -K is still in the keychain. Weird, huh?

It turns out there is one more hoop to jump through. Open your SSH config file and add the following:

Host * AddKeysToAgent yes UseKeychain yes

Now, SSH will look for key in keychain and if it finds it you will not be prompted for password. Key will also be added to ssh-agent. On MacOS this will work on MacOS Sierra 10.12.2 or later. On Linux you can use something like gnome-keyring and it might work even without this last modification to SSH config. As for Windows - who knows, right?

I hope someone found this useful. Now go and configure your SSH config file!

Learn more about SSH:

  • The ultimate guide to SSH keys
  • A top-down introduction to SSH