SSH (Secure Shell) — это клиент-серверный протокол для подключения и аутентификации на удалённом сервере.
Аутентификация означает, что удалённый сервер может подтвердить, что это действительно вы, а не кто-то другой, говорящий от вашего имени.
Возможно, вы уже используете аутентификацию SSH на GitHub, но знаете ли вы, как она работает на самом деле? В этой статье вы узнаете, что происходит «под капотом» и как на самом деле работает аутентификация SSH.
По ходу дела вы познакомитесь с основными понятиями криптографии, которые должен знать каждый разработчик: шифрование с симметричным ключом, шифрование с асимметричным ключом, криптографические хеш-функции и цифровые подписи.
У некоторых разработчиков обычно нет возможности изучить и понять основы криптографии, но эти концепции помогут вам в долгосрочной перспективе. Кроме того, они помогут вам принимать более обоснованные решения по обеспечению безопасности ваших производственных веб-приложений.
Давайте начнём!
Во-первых, почему аутентификация так важна?
Когда мы запускаем git push, GitHub должен убедиться, что с GitHub взаимодействует именно тот человек, который должен. Представьте, что злоумышленник смог бы сделать git push от вашего имени.
Тогда все ваши репозитории окажутся под контролем злоумышленника. Он может удалить весь ваш код вместе со всей историей коммитов.
Звучит довольно опасно, не так ли? Поэтому, чтобы убедиться, что с GitHub общаетесь именно вы, а не злоумышленник, у GitHub есть несколько способов вашей аутентификации.
Наиболее широко используемым методом аутентификации с помощью GitHub является SSH-аутентификация.
Прежде чем мы поймём, как работает аутентификация SSH, нам нужно разобраться в основных концепциях криптографии, а именно: шифрование с симметричным ключом, шифрование с асимметричным ключом, криптографические хеш-функции и цифровые подписи.
Давайте начнем!
Шифрование с симметричным ключом
В древности правители изобретали различные способы передачи секретных военных сообщений своим военачальникам.
Один из самых ранних методов, который, вероятно, использовали древнегреческие правители и, возможно, позднее римляне, заключался в использовании цилиндрического деревянного стержня, называемого Скитала.
Перед военным вторжением правитель заказывал два одинаковых цилиндрических деревянных стержня, называемых скиталами. Затем он отдавал один скитал военачальнику, а другой оставлял себе.
Устройство работало за счёт того, что вокруг штока наматывалась полоска кожи. После этого правитель писал сообщение поверх намотанной полоски кожи, чтобы его можно было прочитать только после повторного наматывания.
Предположим, что на кожаной ленте можно было написать три буквы по кругу и пять букв вдоль/поперек. Намотанная кожаная лента с написанным на ней сообщением attackfromright выглядела бы так:
| | | | | |
| a | t | t | a | c | |
__| k | f | r | o | m |__|
| | r | i | g | h | t |
| | | | | | |
Написав послание на свитке, правитель разматывал кожаную ленту и отправлял её командующему армией. Когда свиток разматывали, на кожаной ленте оказывалось следующее зашифрованное послание:
----------------
akrtfitrgaohcmt
----------------
Итак, теперь вы видите, что даже если бы кожаную ленту перехватил вражеский шпион, сообщение не имело бы смысла. Разве это не удивительно? Разумное использование деревянного стержня и кожаной ленты могло помочь некоторым древним правителям выигрывать сражения!
Когда кожаная лента доходила до командующего армией, он наматывал её на свой скиталь (который был точно таким же, как у правителя), и тогда командующему становилось понятно сообщение.
Эта техника шифрования на самом деле является примером симметричного шифрования на практике.
Шифрование — это процесс, при котором исходное сообщение изменяется (или кодируется) таким образом, что только предполагаемый получатель может расшифровать и увидеть исходное сообщение.
Исходное сообщение называется открытым текстом, а закодированное — зашифрованным. Шифрование преобразует plaintext to ciphertext с помощью ключа.
Чтобы расшифровать сообщение, то есть преобразовать ciphertext to plaintext, человек должен иметь доступ к тому же ключу.
Если сравнить это с техникой «сцитала», то «сцитал» — это ключ. Правитель передаёт ключ (сцитал) только командующему армией, которому нужно знать, о чём говорится в послании.
Вот как выглядит процесс шифрования:
Процесс расшифровки будет выглядеть следующим образом:
Мы называем это шифрованием с симметричным ключом, потому что для шифрования и расшифровки сообщения используется один и тот же ключ.
Этот ключ (шифровальный код) должен быть защищён от доступа противника. Если противник получит доступ к этому ключу, он сможет расшифровать сообщения.
Но есть и другой тип шифрования — асимметричное шифрование. Теперь, когда вы разобрались с симметричным шифрованием, давайте перейдём к асимметричному шифрованию.
Шифрование с Асимметричным ключом
При шифровании симметричным ключом, как мы видели выше, и правитель, и командующий армией использовали один и тот же ключ для шифрования и расшифровки сообщения.
Но при шифровании с асимметричным ключом используются два ключа (называемые парой ключей). Один из этих двух ключей является закрытым, а другой — открытым.
Открытый ключ может быть доступен всем (поэтому он называется открытым). Но закрытый ключ должен храниться в секрете! Его ни в коем случае нельзя никому раскрывать.
Интересная особенность шифрования с помощью асимметричного ключа заключается в том, что если сообщение зашифровано с помощью открытого ключа, то расшифровать его можно только с помощью соответствующего закрытого ключа.
Никакой другой ключ не сможет его расшифровать.
И наоборот, тоже работает. Если сообщение зашифровано с помощью закрытого ключа, то расшифровать его можно только с помощью соответствующего открытого ключа.
Два ключа — открытый и закрытый — математически связаны друг с другом. Один ключ шифрует, другой расшифровывает.
Просто небольшое примечание: шифрование с помощью асимметричного ключа также называют шифрованием с помощью открытого ключа. Эти два термина взаимозаменяемы, но означают одно и то же.
Криптографические хэш — функции
Криптографическая хеш-функция предназначена для обработки входных данных любой длины и выдачи выходных данных фиксированной длины. Выходные данные фиксированной длины называются хеш-значением.
Популярным примером криптографической хэш-функции является SHA-256.
На изображении выше показано значение хэша SHA-256 для входных данных «freeCodeCamp.org». Криптографическая хеш-функция обладает тремя свойствами, которые делают её очень полезной (мы рассмотрим их в следующих разделах).
Во-первых, практически невозможно взять значение хэша и вычислить входные данные по значению хэша.
Например, если нам дано хеш-значение c9c31315ef2257e4b7698, мы не сможем определить, что входными данными для хеш-функции было «freeCodeCamp.org».
Во-вторых, если мы передадим один и тот же ввод в хеш-функцию, мы получим одно и то же хеш-значение на выходе.
Если мы снова передадим «freeCodeCamp.org» в функцию хеширования SHA-256, мы получим тот же результат, что и при предыдущем вызове.
В-третьих, два разных входных данных никогда не будут иметь одинаковое хеш-значение. Даже малейшее изменение входных данных приводит к совершенно другому результату.
Предположим, что если мы введём «freeCodeCamp» вместо «freeCodeCamp.org», то получим совершенно другой результат.
Цифровые подписи
В повседневной жизни вам, возможно, приходится подписывать различные документы. Это могут быть юридические документы, табель успеваемости ваших детей или что-то ещё.
Когда вы ставите свою подпись под документом, это означает, что вы согласны с тем, что написано в этом документе.
Позже вы не сможете отказаться от выполнения того, что написано в документе. Верно?
Точно так же в цифровом мире у нас есть цифровые подписи — или мы можем просто называть их подписями.
Давайте разберёмся, как работают подписи, на примере. У нас есть два пользователя, которых зовут «Элис (Alice)» и «Боб (Bob)».
Боб хочет перевести немного денег на банковский счёт Алисы. Поэтому Боб спрашивает Алису о реквизитах её банковского счёта.
Алиса знает о цифровых подписях и решила воспользоваться одной из них. В конце вы поймёте, почему Алиса выбрала цифровую подпись.
Прежде чем Алиса сможет создать цифровую подпись. Алиса предоставляет Бобу свой открытый ключ (а закрытый ключ оставляет у себя).
Затем Алиса создаёт цифровую подпись и размещает её в конце документа.
Цифровая подпись создаётся путём передачи содержимого документа в криптографическую хеш-функцию, например SHA-256. В случае Алисы содержимое документа — это номер её банковского счёта.
Как только мы получаем хеш-значение, оно шифруется с помощью закрытого ключа Алисы. Результатом этого шифрования является подпись, которая размещается в конце документа.
Затем это сообщение отправляется Бобу через Интернет.
Когда Боб получает этот документ, он проверяет, действительна ли подпись.
Чтобы проверить подпись, Боб сначала расшифровывает её с помощью открытого ключа Алисы. Если вы помните, Алиса сгенерировала подпись, зашифровав значение хэша.
plaintext ciphertext
| |
| |
| |
hash value --------encrypt--------> signature
Итак, когда Боб расшифрует подпись, он получит значение хэша, которое рассчитала Алиса. Давайте назовём это значением хэша Алисы.
ciphertext plaintext
| |
| |
| |
signature --------decrypt--------> hash value
Затем Боб берёт номер банковского счёта, указанный в документе, и передаёт его в хеш-функцию.
Наконец, Боб сравнивает значение хэша Алисы (расшифрованную подпись) со значением хэша, которое он только что рассчитал. Если оба значения хэша совпадают, значит, подпись действительна.
Хорошо, но зачем нам всё это делать? Что это значит, если подпись действительна?
Когда проверка подписи проходит успешно, это доказывает две вещи.
Во-первых, это доказывает, что документ был отправлен только Алисой. Никто другой не мог отправить этот документ.
Мы можем быть уверены, что этот документ отправила только Алиса, потому что нам удалось расшифровать подпись с помощью открытого ключа Алисы.
Мы узнали, что если что-то зашифровано с помощью закрытого ключа, то расшифровать это можно только с помощью связанного с ним открытого ключа.
Итак, если Боб успешно расшифровал подпись с помощью открытого ключа Алисы, это означает, что она была зашифрована с помощью закрытого ключа Алисы, верно?
И только у Алисы есть доступ к её личному ключу. Это значит, что Алиса — единственный человек, который мог отправить этот документ!
Во-вторых, это доказывает, что содержимое сообщения не было изменено злоумышленником во время передачи по сети.
Мы сделали две вещи, чтобы проверить подпись. Мы расшифровали подпись, и она дала нам значение хэша, которое рассчитала Алиса. Мы также хэшировали полученный номер банковского счёта.
Если вычисленное Алисой хеш-значение совпадает с вычисленным Бобом хеш-значением, это означает, что Алиса и Боб ввели в хеш-функцию одни и те же данные.
И это означает, что номер банковского счёта, который отправила Алиса и который получил Боб, абсолютно идентичны.
Если бы злоумышленник изменил номер банковского счёта до того, как документ попал к Бобу, то Боб получил бы изменённый номер банковского счёта.
Когда Боб попытался вычислить хэш-значение этого изменённого номера банковского счёта, хэш-значение получилось другим, чем то, которое вычислила Алиса.
Таким образом, при сопоставлении хэш-значения Алисы (расшифрованной подписи) и хэш-значения, рассчитанного Бобом, сопоставление не удастся. И это помешает Бобу перевести деньги на неправильный номер банковского счёта.
В заключение, когда подпись успешно проверена, это означает, что:
- Этот документ только от Алисы.
- Содержание документа не было изменено какой-либо третьей стороной.
Теперь вы узнали о шифровании симметричным ключом, шифровании асимметричным ключом, криптографических хэш-функциях и цифровых подписях. Это потрясающе!
Мы создали действительно прочную основу. Теперь вам будет гораздо проще разобраться в аутентификации SSH.
Как работает SSH-аутентификация
Если вы не настроили аутентификацию SSH с помощью GitHub, то после прочтения этой статьи вы можете ознакомиться с подробной документацией GitHub о том, как это сделать. А пока, пожалуйста, дочитайте статью до конца.
Суть процесса настройки заключается в том, что вы создаёте пару открытого и закрытого ключей на своём локальном компьютере. Затем вы загружаете свой открытый ключ в свой профиль GitHub — и всё!
После создания пары открытого и закрытого ключей в Ubuntu пара открытого и закрытого ключей хранится в каталоге ~/.ssh.
На изображении выше показан мой открытый ключ. Я загрузил этот открытый ключ в свой профиль на GitHub:
Теперь, когда я запускаю git push или любую другую команду, которая взаимодействует с GitHub, я буду проходить аутентификацию с помощью SSH.
SSH — это протокол клиент-сервер. Наш компьютер, на котором запущен git push — это клиент SSH. GitHub — это сервер SSH.
Клиент начинает процесс аутентификации с получения нашего открытого ключа, который находится внутри ~/.ssh.
Затем клиент подготавливает сообщение с нашим открытым ключом. После этого клиент генерирует подпись с помощью соответствующего закрытого ключа.
Открытый ключ и подпись отправляются на GitHub. Получив это сообщение, GitHub выполняет две задачи:
Сначала он проверяет, связан ли открытый ключ, упомянутый в сообщении, с профилем GitHub. Поскольку мы загружаем наш открытый ключ на GitHub, этот шаг выполняется успешно.
Во-вторых, GitHub проверяет подпись с помощью открытого ключа, который мы загрузили.
Мы узнали, что если проверка подписи прошла успешно, это означает, что сообщение мог отправить только тот, у кого есть соответствующий закрытый ключ.
Поскольку только у нас есть закрытый ключ, связанный с загруженным открытым ключом, это доказывает GitHub, что именно мы пытаемся связаться с GitHub, а не злоумышленник.
Теперь GitHub на 100% уверен, что мы — это мы, мы успешно прошли аутентификацию, и нашему git push разрешено продолжить.
Видите, разобраться в аутентификации SSH стало так просто, ведь вы уже изучили основы.
Приведённое выше изображение взято из популярного комикса xkcd. Персонаж (по имени Кьюболл) размышляет о том, чтобы раскрыть свой закрытый ключ. Надеюсь, теперь вы знаете, почему раскрывать свой закрытый ключ не стоит.
Если вы раскроете свой закрытый ключ, кто-то другой сможет пройти аутентификацию на GitHub от вашего имени. Вы же не хотите, чтобы это произошло, верно? 😉
Поэтому всегда храните свой секретный ключ только для себя.
Подводя итог всему этому
Если вы дочитали до этого места, то поздравляю 🥳.
Вы узнали, как на самом деле работает аутентификация SSH: когда GitHub успешно проверяет подпись, это подтверждает, что с ним разговариваем мы, а не злоумышленник.
По ходу дела вы получили базовые знания о шифровании с симметричным ключом, шифровании с асимметричным ключом, криптографических хэш-функциях и цифровых подписях.
Спасибо, что были со мной в этот раз. Надеюсь, вы узнали что-то новое и ценное.