Чтобы сделать это более понятным и ясным:
Помните, что здесь задействовано как минимум два компьютера: ваш, где вы храните различные файлы и настройки и GitHub's. (GitHub использует несколько компьютеров, но они притворяются одним компьютером.)
Ваш компьютер вызывает GitHub через Inte rnet, как если бы он звонил. Затем ваш компьютер передает какую-либо форму учетные данные . Их компьютер проверяет эти учетные данные и решает, являетесь ли вы тем, кем себя называете.
Передаваемые вами учетные данные зависят от того, как вы выполняете вызов. Если вы делаете вызов, используя https://..., Git использует диспетчер учетных данных . Каждая ОС имеет свой собственный набор диспетчеров учетных данных, который может использовать Git, поэтому процесс здесь очень отличается от Windows, MacOS, Linux и т. Д. Если вы делаете вызов, используя ssh://..., все ОС имеют достаточно общей базы кода S SH, чтобы все они действовали почти одинаково на этом этапе, хотя все еще есть элементы, определяемые ОС c, которые появляются .
Поскольку вы используете S SH, то (один, но см. Ниже) учетные данные, которые вы передаете, являются ключом publi c s sh (также используя шифрование, используя ваш закрытый ключ - см., Например, эту статью о Digital Ocean ). Ваш ключ sh хранится в определенном для ОС c (и настраиваемом) месте. В вашем конкретном случае это было $HOME/.ssh/id_rsa.pub. Имя без .pub в конце - это закрытый ключ, и эти ключи идут парами.
Когда GitHub получает ваш ключ, они ищут его в гигантской таблице, в которой они сохраняйте каждый ключ, который им дали все . Ваш ключ никогда не совпадает с чьим-либо еще ключом. Ключ, который вы им дали, имеет имя пользователя , связанное с ним, когда вы давали им этот ключ. Так как только у вас есть этот ключ (и закрытый ключ, который go с ним), теперь GitHub может быть уверен, что вы тот, кем вы только что заявили.
Заявка полностью произошла через эту публикацию c ключ. Если вы больше не хотите претендовать на то, чтобы быть таким человеком, передайте ключ Отличный publi c. Вам также нужно будет войти в систему Git и дать им новый или обновленный ключ publi c. Это должно произойти после того, как вы сгенерировали пару открытого / закрытого ключа, и до того, как вы используете ssh для подключения вашего компьютера и вашего Git к их компьютеру с их Git.
Здесь необходимо знать о двух важных вещах, которые усложняют эту относительно простую картину. Опять же, упрощенное изображение: Существует одна пара ключей. Вы храните на GitHub ваш ключ publi c из этой одной пары ключей. Позже ваш Git вызывает GitHub через ssh. Ваши ssh и их sshd обмениваются некоторыми данными. Ваш s sh использует шифрование с использованием обоих ключей из вашей пары ключей. Теперь они знают, что вы - это вы, потому что они могут сопоставить все, используя свою копию вашего открытого ключа c, и only , у вас есть private key, который удалось разблокировать данные. Но вы можете захотеть сохранить более одной пары ключей на вашем компьютере, и это все усложнит.
Предоставление разных ключей разным получателям
Общее программное обеспечение s sh может последовательно пробовать различные пары ключей. См. Раздел ниже о нескольких ключах для (многих и сложных) деталей. Однако вы можете указать ему попробовать один конкретный файл , выбрав этот файл на основе хоста, на котором вы * sh, используя файл config ($HOME/.ssh/config) , Например, предположим, что вы хотите, чтобы все соединения с github.com использовали только пару ключей private-and-publi c, хранящихся в файлах $HOME/.ssh/id_rsa.github и $HOME/.ssh/id_rsa.github.pub. Тогда:
Host github.com
IdentitiesOnly yes
IdentityFile ~/.ssh/id_rsa.github
сделает это. Первая строка, Host github.com, сообщает S SH, что приведенные ниже записи относятся к сеансам с хостом с именем github.com. (Шаблоны глобусов здесь разрешены, поэтому, если в вашей работе, в школе или где-либо еще есть хосты, имена которых совпадают с *.example.com, вы можете использовать такой шаблон глобуса.)
Вторая строка, IdentitiesOnly yes, переопределяет предложенные идентификаторы через с sh -агент . Вы можете или не можете сделать это! Если вы используете s sh -агент для идентификации, это намеренно побеждает (по крайней мере, некоторые из) предложений агента. Подробности см. В следующем разделе.
Последняя строка, IdentityFile <em>path</em>, задает имя ключа или файла пары ключей. ssh добавит или удалит .pub при необходимости здесь. (Существуют некоторые различия в версиях s sh, и вы можете хотеть или не хотеть .pub; используйте то, что вам подходит.)
Оба ssh (пользовательская команда, которая вас используется для подключения к серверу) и sshd (команда на сервере, к которому подключается ваш sh), очень настраиваемые. Полный список параметров конфигурации s sh см. на странице руководства ssh_config .
Агенты и IdentityFile записи
В каждом разделе конфигурации хоста Ваш $HOME/.ssh/config файл, вы можете поместить в несколько IdentityFile строк. Если вы это сделаете, s sh предложит каждый ключ, пока один из них не будет принят, или у него не останется ключей для предложения.
Если у вас есть нет IdentityFile строк, ваш S SH имеет некоторые встроенные значения по умолчанию. Они немного отличаются от одной версии S SH (и ОС) к другой; см. собственную ssh_config документацию для списка вашей системы, но в приведенной выше документации написано:
По умолчанию ... ~/.ssh/id_rsa и ~/.ssh/id_dsa для протокола версия 2.
(сейчас шифрование DSA по крайней мере устарело и, по большей части, полностью не поддерживается. Шифрование ECDSA, как мне кажется, является в настоящее время любимым, хотя шифрование не является моей областью.)
В отсутствие IdentitiesOnly yes S SH может также предлагать все идентификационные данные - то есть ключи - предоставленные вашим S SH Агентом . Агент - это вспомогательная система, которая позволяет вам отправлять ключи с одного компьютера (ваш самый надежный) на другой, не сохраняя их в файлах на менее доверенном компьютере. То, как это работает, выглядит относительно просто, в целом: когда ваш s sh связывается с другим хостом H , если вы не сказали IdentitiesOnly yes, ваш sh связывается с вашим агентом и спрашивает it , какие ключи попробовать. Он будет пробовать эти ключи на хосте H , по одному за раз. Если ни один из них не работает, у него все еще есть какой-либо локально сохраненный файл и / или файлы, перечисленные в записях IdentityFile.
Детали, однако, сложны. Во-первых, обратите внимание, что сам агент состоит из двух частей. (Это не обязательно отдельные программы, но о системе проще думать, описывая каждую как отдельную вещь.)
Одна часть выполняется на машине, которую вы делаете trust (с ключами, хранящимися в файлах).
Другая часть запускается на компьютере, на который вы входите, через ssh с этого доверенного компьютера. .
Обе машины запускают агента. Иногда вы можете запустить более одного агента на каждой машине, и опять-таки детали могут немного отличаться от одной ОС к другой - например, в MacOS, при простом входе в систему создается агент, который затем может использовать весь терминал windows , Из любого окна терминала вы запускаете ssh less-trusted-machine и запускаете новый сеанс на менее доверенной машине, а it также вызывает агента или использует уже имеющийся у вас агент или что-то еще.
Теперь вы используете Git на второй машине. sh компьютера с меньшим доверием замечает, что есть агент, и запрашивает у него ключи. Этот агент связывается с агентом на вашем более доверенном компьютере. Агент на вашем более доверенном компьютере извлекает ключи и передает их или не передает, все в зависимости от того, какие правила используют два агента и различные экземпляры s sh.
Следовательно, когда вы используете агент, набор ключей, которыми менее доверенная машина имеет (или имеет доступ), зависит от того, какой агент на more доверенная машина делает. Вот почему эта картина сложна.
Если вы вообще не используете агент или если в интерпретаторе командной строки вы собираетесь запустить ssh или запустить Git ssh, вы полностью победили агента, 1 s sh, который вы запускаете или запускаете Git, имеет доступ только к тем удостоверениям (парам ключей), которые есть в вашем $HOME/.ssh/ или другое специфицированное для ОС c место, где вы положили такие ключи. Конечно, он по-прежнему имеет доступ к всем ключам, которые вы там положили. Строка IdentitiesOnly yes в вашей конфигурации теперь означает, что использует только файлы, которые я перечислил здесь. Это довольно просто: вы перечисляете файлы - или, вернее, один из каждой пары файлов, и помещаете ключи в файлы .
Если вы используете с помощью агента, s sh, который вы используете или Git, имеете доступ к дополнительным парам ключей. Добавление IdentitiesOnly здесь сложно. Это не помешает вашему s sh связаться с агентом, но каждый из ключей, возвращаемых агентом, имеет идентификатор . Вы можете указать s sh, что вы используете , использовать только те удостоверения, которые соответствуют файлам, указанным мной в разделе IdentityFile. Это означает, что вы можете хранить только публичные c key , а не publi c и файлы пар закрытых ключей. Если вы не очень доверяете этой машине - той, которую я называл машиной с меньшей степенью доверия, - это дает вам возможность полностью исключить использование личного ключа с помощью агента.
Последнее, На какой бы машине вы ни делали хранили как публичные c, так и личные ключи, вы можете шифровать их. Теперь вам нужно ввести пароль или пароль, чтобы разблокировать их. Это может раздражать, но с помощью агента вы можете один раз разблокировать их для агента и доверять агенту, чтобы они были надежно защищены в памяти. (Как очень вы можете доверять этому агенту ... ну, это совсем другая проблема!)
Слишком много ключей
Фактическая разблокировка и проверка того, кто вы есть утверждается, что обычно это происходит внутри sshd, серверного программного обеспечения, которое реализует s sh. Ваш s sh вызывает свой sshd и передает ключ со всеми протоколами шифрования и тому подобным. Они пробуют это в замке, используя ключевую часть publi c пары ключей, и это работает ... или не работает - и если это не работает, они могут предложить вам больше пытается. Это настраивается на сервере.
Теперь предположим, что вы используете агент и в вашем агенте хранится пятьдесят (50) различных ключей. Ваш s sh, на каком бы компьютере вы ни находились - каким бы надежным он ни был, - получает один ключ от агента и передает его sshd, и это бесполезно. Ваш s sh получает следующий ключ от агента и пробует его, и это тоже не тот ключ. Это похоже на то, что вы нащупываете 50 ключей на связке ключей, даже не глядя на каждую клавишу, и пытаетесь запереть ее в замке. Через некоторое время sshd на сервере встревожены повторяющимися сбоями: похоже, вы пытаетесь взломать.
Фактическое количество попыток зависит от сервера, так как оно настраивается. Но если у вас есть много ключей, будет хорошей идеей попробовать правую клавишу (только или сначала). Для этого вам понадобится строка IdentitiesOnly yes, независимо от того, используете ли вы агент :
Если вы не используете агент, IdentitiesOnly yes означает, что использует только пары открытого и закрытого ключей, перечисленные здесь в каждой записи конфигурации IdentityFile. Таким образом, вы перечисляете правильный, а ваш sh использует правильный, и он соответствует lock и их sshd любит вас, и все хорошо.
Если вы используете агент, IdentitiesOnly yes означает , используйте ключ (и) агента, который соответствует publi c - ключ, указанный в записи конфигурации IdentityFile или записи здесь . Таким образом, вы перечисляете правильный, а ваш s sh использует правильный, и, как и раньше, все хорошо.
Если вы используете агент, но имеете только несколько ключей - всего один или два, а может быть, даже до шести или около того, в зависимости от конфигурации sshd на вызываемых вами серверах - вам не нужны IdentitiesOnly yes и IdentityFile строки. Но они не будут причинять боль , пока вы правильно их понимаете.
Соединяя все это вместе
Вы можете (и на самом деле должен) хранить файлы пары ключей где-нибудь на компьютере, которому доверяют. Вы также можете зашифровать , так что вы должны ввести пароль или пароль, чтобы разблокировать их, хотя это может раздражать. Агент может помочь. Вам может (вероятно, понадобится) загрузить ключей в этого агента, используя ssh-add.
Когда вы sh переходите с одного компьютера на другой, вы можете пусть ваш агент перенаправит новому агенту на следующем компьютере. Второй и все последующие компьютеры в цепочке нуждаются в ключе пары ключей publi c, чтобы убедиться, что вы - это вы, но если вы настроили переадресацию агента, им не нужно закрытый ключ.
Каждый компьютер в этой цепочке доверия, на который вы ssh заходите с более доверенного компьютера, принимает зашифрованные данные, которые вы отправляете изначально, при запуске сессия sh. Они используют сохраненный ключ publi c , который вы каким-то образом (любым способом, каким вам нравится / можете) уже хранится на менее доверенном компьютере, чтобы узнать, знаете ли вы private ключ Если вы это сделаете, вы должны быть самим собой.
За исключением того факта, что они представили свои sshd, GitHub на самом деле ничем не отличается: это просто компьютер с меньшим доверием что вы входите в систему (как git@github.com). Они берут ключ, который вы им даете, и ищут его, но вместо того, чтобы просто иметь один ключ для вас , у них есть один ключ для каждой учетной записи, которая существует на GitHub . Они пробуют ключ, который вы им дадите, и посмотрите, сработает ли он в замке для Алисы. Нет? Не должно быть Алиса; попробуйте это в замке для Боба. Нет? Попробуйте Кэрол - и так далее, пока, возможно, не откроются Фред, или Рита, или Зак. Когда они доберутся до сохраненного .pub ключа, который работает , ну, это должно быть то, кем вы являетесь. 2
1 В сеансе оболочки вы увидите переменную среды SSH_AUTH_SOCK, которая содержит путь, по которому ssh вы запускаете на эта машина связывается с агентом. Если вы переопределяете или отменяете переменную среды, это побеждает агента.
Чтобы узнать, активен ли агент и, если да, к каким ключам он имеет доступ, используйте ssh-add -l.
* 1320. *
2 Пробовать одну и ту же личность в одно и то же время, линейно через тысячи или миллионы личностей, слишком медленно, поэтому GitHub должен обязательно использовать другую стратегию для внутреннего использования. Но эффект тот же: вы дали им идентификационную битовую строку, используя пару открытых / закрытых ключей и шифрование, от своего s sh до их sshd. Они используют собранные авторизованные ключи для
каждого и находят уникального
кого-то в этой куче, и кого бы они ни нашли, это
вас . Если они никого не находят, они отклоняют ключ, и ваш sh может go предложить другой ключ, вплоть до любого предела, установленного в
их sshd.