☰

Как организовать SSH-ключи?

tag-icon • tag-icon ssh ssh-agent
Как организовать SSH-ключи?

Я создал несколько ключей SSH в Debian для разных учетных записей (а именно Digital Ocean, GitHub и Bitbucket), но все это очень быстро становится запутанным.

Перечислив содержимое моей папки .ssh, я получаю:

digOcn digOcn.pub github github.pub id_rsa id_rsa.pub

(Я использую id_rsaключ для Bitbucket.)

Я делаю eval 'ssh-agent -s'это, а затем «добавляю» ключи вот так:

  • ssh-add ~/.ssh/github(и затем вводим парольную фразу)

  • ssh-add ~/.ssh/id_rsa(и затем вводим парольную фразу)

  • ssh-add ~/.ssh/digOcn(Когда я пытаюсь добавить digOcn, появляется сообщение «Отказано в доступе». Я не пытаюсь sudoизбежать ошибок, а также потому, что другие ключи не требуют sudo.)

А вот что сбивает с толку: выступление ssh-add -lдает мне следующее:

2048 so:me:nu:mb:er:s0:an:d9:le:tt:er:s0 /home/USER/.ssh/id_rsa (RSA)
2048 so:me:nu:mb:er:s0:an:d9:le:tt:er:s0 /home/USER/.ssh/github (RSA)
2048 so:me:nu:mb:er:s0:an:d9:le:tt:er:s0 github (RSA)
2048 so:me:nu:mb:er:s0:an:d9:le:tt:er:s0 USER@COMPUTER_NAME (RSA)

Да, я добавлял ключи SSH в прошлом, но я не могу отследить, что я сделал. Вероятно, поэтому есть и то, и другое/home/USER/.ssh/github и github.

Что я сделал не так? Как мне организовать мои SSH-ключи?

решение1

Во-первых, нет ничего плохого в использовании разных ключей для разных аккаунтов. Это довольно излишне для интерактивных оболочек, но есть законные причины делать это, когда вы имеете дело с другими, неинтерактивными сервисами. Например, несколько лет назад GitHub начал разрешать более сильные ключи SSH, в то время как Bitbucket настаивал на использовании более слабых еще некоторое время. Правильным действием в то время было использовать разные ключи для доступа к GitHub и Bitbucket.

Другой пример — rsync. Если вы используете rsync, скажем, для развертывания файлов на веб-сервере, то вам, вероятно, понадобятся выделенные ключи SSH для этого. Они позволяют вам устанавливать другие разрешения, чем те, которые вы обычно используете для своей интерактивной учетной записи.

Возвращаясь к вашему вопросу об управлении несколькими ключами: SSH позволяет вам устанавливать различные параметры для различных направлений. Для этого вам нужно отредактировать файл ~/.ssh/configследующим образом:

Host  bitbucket.org
    User                    hg
    IdentitiesOnly          yes
    IdentityFile            /home/user/.ssh/bitbucket

Host  github.com  gist.github.com
    User                    git
    IdentitiesOnly          yes
    IdentityFile            /home/user/.ssh/github

Файл ~/.ssh/configдолжен иметь права доступа 0600 (сейчас я не помню, предусмотрено ли это SSH или нет, но это точно не повредит).

Конечно, вы можете использовать тот же механизм для интерактивных оболочек, поэтому задайте такие параметры, как удаленное имя пользователя (если оно отличается от локального), удаленный порт, сократите имя хоста и т. д. Например:

Host  sm
    Hostname                sphygmomanometer.example.com
    User                    human
    Port                    2222

Тогда вы можете просто бежать.

ssh sm

вместо

ssh -p 2222 [email protected]

Также разрешены подстановочные знаки:

Host *
    ControlPath             ~/.ssh/ctl-%u-%r-%h-%p
    ControlMaster           auto
    ControlPersist          5m

Более подробную информацию читайте в руководстве.

Последний, но тем не менее важный:не"сделай eval 'ssh-agent -s'дело". Вопреки распространенному мнению, это имеет серьезные последствия для безопасности. Правильный способ сделать это так:

ssh-agent /bin/bash
ssh-add

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

Это запускает новую оболочку, в которую загружены ваши ключи, и когда вы хотите отозвать доступ, вы просто используете exitэту оболочку. Если вы «сделаете это eval 'ssh-agent -s'», то агенты аутентификации останутся запущенными еще долго после того, как вы выйдете из системы, и они могут (и в конечном итоге будут) использоваться для несанкционированного доступа.

Редактировать:Попробуйте провести этот небольшой эксперимент:

  1. eval $(ssh-agent -s)
  2. выйдите из системы или убейте терминал
  3. войдите снова или откройте новый терминал
  4. pgrep ssh-agent

Никто их не убивает ssh-agent, они висят до следующего раза reboot, готовые к использованию новейшими вредоносными программами.

Связанный контент