#продолжи_мысль_SE
Зачем админ просит публичный ключ. Или что происходит при подключении к серверу по SSH
Если вы работаете аналитиком, архитектором, техническим писателем и «около этого», наверняка сталкивались с просьбами от админов вроде «Скинь свой публичный ключ». После того как вы это сделаете, получаете возможность «ходить» по серверам на стейдже, препроде, проде и т.д.
А зачем вообще нужен этот ключ и что происходит, когда мы пытаемся подключиться к серверу по SSH? Давайте разберемся (без захода в дебри).
Публичный и приватный ключ
Публичный ключ SSH (пример: user_rsa.pub) всегда существует в паре с приватным ключом, который носит такое же название, но не имеет расширения .pub (для нашего примера — user_rsa). Без приватного ключа публичный будет бесполезным.
И здесь важно запомнить: никому не передавайте свой приватный ключ. А публичный можете отправлять по запросу без проблем.
Зачем админу ваш публичный ключ
После получения публичного ключа админ помещает его в файл ~/.ssh/authorized_keys на сервере. И после этого вы можете подключаться к серверу по SHH.
А подключение происходит так (при условии, что оно не первое, про особенности первого — ниже):
1. Вы вводите в консоли команду для подключения к серверу (например, ssh user@93.184.216.34).
2. Сервер находит ваш публичный ключ в ~/.ssh/authorized_keys.
3. Сервер генерирует число, шифрует его с использованием вашего публичного ключа (генерирует challenge) и отправляет challenge в ответ вашему компьютеру.
4. Установленный на вашем компьютере SSH-агент расшифровывает с его помощью приватного ключа полученный challenge. Затем он создает подпись (которая содержит хеш от расшифрованного числа и данные сессии) и отправляет ее серверу.
5. Получив подпись, сервер сверяет ее с подписью, вычисленной локально с помощью публичного ключа (она тоже содержит хеш от числа и данные сессии).
6. Если подписи совпали, сервер разрешает доступ.
Этот процесс описан на диаграмме, прикрепленной к посту.
Если вы подключаетесь к серверу впервые
В этом случае после ввода в консоли команды для подключения к серверу и отправки запроса, сервер предъявляет в ответ свой публичный ключ (fingerprint). Получив его, компьютер спрашивает, добавить ли в доверенные. При положительном ответе fingerprint сервера добавляется в known_hosts на вашем компьютере. И теперь все работает, как описано выше (при запросе подключения к серверу он предъявляет свой fingerprint, чтобы подтвердить, что это реально он).
Почему публичный ключ, а не логин и пароль
Вариант с публичным ключом считается более безопасным.
При использовании логина и пароля последний передается по сети. А значит, есть вероятность его компрометации в случае перехвата злоумышленниками. Конечно, полностью отказываться от этого способа не стоит. Если вы, к примеру, работаете в приватной сети, изолированной от внешнего мира, логин и пароль — вполне ОК. Если же вы подключаетесь к серверу через публичную сеть, использование публичного и приватного ключей — must have.
Можно ли расшифровать число, отправляемое сервером с помощью публичного ключа
Если злоумышленник попытается использовать публичный ключ для расшифровки числа от сервера, чтобы выдать себя за вас, ничего не получится. Ведь здесь используются алгоритмы асимметричного шифрования, которые подразумевают соответствие принципам:
• Невозможность использования публичного ключа для расшифровки данных, даже если они зашифрованы им же.
• Невозможность создания подписи с помощью публичного ключа.
• Невозможность (ну или почти невозможность) математически вычислить приватный ключ с помощью публичного. Это требует колоссальных ресурсов (тысячи лет).
Участвую в конкурсе «Продолжи мысль» от @systems_education
Зачем админ просит публичный ключ. Или что происходит при подключении к серверу по SSH
Если вы работаете аналитиком, архитектором, техническим писателем и «около этого», наверняка сталкивались с просьбами от админов вроде «Скинь свой публичный ключ». После того как вы это сделаете, получаете возможность «ходить» по серверам на стейдже, препроде, проде и т.д.
А зачем вообще нужен этот ключ и что происходит, когда мы пытаемся подключиться к серверу по SSH? Давайте разберемся (без захода в дебри).
Публичный и приватный ключ
Публичный ключ SSH (пример: user_rsa.pub) всегда существует в паре с приватным ключом, который носит такое же название, но не имеет расширения .pub (для нашего примера — user_rsa). Без приватного ключа публичный будет бесполезным.
И здесь важно запомнить: никому не передавайте свой приватный ключ. А публичный можете отправлять по запросу без проблем.
Зачем админу ваш публичный ключ
После получения публичного ключа админ помещает его в файл ~/.ssh/authorized_keys на сервере. И после этого вы можете подключаться к серверу по SHH.
А подключение происходит так (при условии, что оно не первое, про особенности первого — ниже):
1. Вы вводите в консоли команду для подключения к серверу (например, ssh user@93.184.216.34).
2. Сервер находит ваш публичный ключ в ~/.ssh/authorized_keys.
3. Сервер генерирует число, шифрует его с использованием вашего публичного ключа (генерирует challenge) и отправляет challenge в ответ вашему компьютеру.
4. Установленный на вашем компьютере SSH-агент расшифровывает с его помощью приватного ключа полученный challenge. Затем он создает подпись (которая содержит хеш от расшифрованного числа и данные сессии) и отправляет ее серверу.
5. Получив подпись, сервер сверяет ее с подписью, вычисленной локально с помощью публичного ключа (она тоже содержит хеш от числа и данные сессии).
6. Если подписи совпали, сервер разрешает доступ.
Этот процесс описан на диаграмме, прикрепленной к посту.
Если вы подключаетесь к серверу впервые
В этом случае после ввода в консоли команды для подключения к серверу и отправки запроса, сервер предъявляет в ответ свой публичный ключ (fingerprint). Получив его, компьютер спрашивает, добавить ли в доверенные. При положительном ответе fingerprint сервера добавляется в known_hosts на вашем компьютере. И теперь все работает, как описано выше (при запросе подключения к серверу он предъявляет свой fingerprint, чтобы подтвердить, что это реально он).
Почему публичный ключ, а не логин и пароль
Вариант с публичным ключом считается более безопасным.
При использовании логина и пароля последний передается по сети. А значит, есть вероятность его компрометации в случае перехвата злоумышленниками. Конечно, полностью отказываться от этого способа не стоит. Если вы, к примеру, работаете в приватной сети, изолированной от внешнего мира, логин и пароль — вполне ОК. Если же вы подключаетесь к серверу через публичную сеть, использование публичного и приватного ключей — must have.
Можно ли расшифровать число, отправляемое сервером с помощью публичного ключа
Если злоумышленник попытается использовать публичный ключ для расшифровки числа от сервера, чтобы выдать себя за вас, ничего не получится. Ведь здесь используются алгоритмы асимметричного шифрования, которые подразумевают соответствие принципам:
• Невозможность использования публичного ключа для расшифровки данных, даже если они зашифрованы им же.
• Невозможность создания подписи с помощью публичного ключа.
• Невозможность (ну или почти невозможность) математически вычислить приватный ключ с помощью публичного. Это требует колоссальных ресурсов (тысячи лет).
Участвую в конкурсе «Продолжи мысль» от @systems_education