Как работает SSH с private key файлом?
Насколько я понимаю, ssh, упрощено работает таким образом:
- Сервер отправляет свой публичный ключ для установления доверия или проверки соответствия, в случае наличия прошлых подключений
- Создается симметричный общий ключ с помощью публичных ключей обоих.
- Клиент отправляет свой публичный ключ для проверки наличия его в authorized_keys
- Если ключ найден, то шифрует какой-то секрет публичным ключом клиента.
- Клиент расшифровывает приватным и отправляет секрет серверу, который тот проверит.
Но в случае, допустим, .pem файла, которые выдает тот же амазон, содержится оба ключа, но на машине, к которой нужно присоединиться нет публичного ключа той машины, которая хочет присоединиться, как в этом случае действует ssh? Просто пропускает вторую часть 3-его шага?
Ответы (2 шт):
Шаг 3 не ограничивается аутентификацией по публичному ключу. В конфигурационном файле сервера sshd_config есть опции, определяющие разрешенные методы аутентификации.
Цитата из man sshd_config:
The available authentication methods are: "gssapi-with-mic", "hostbased", "keyboard-interactive", "none" (used for access to password-less accounts when PermitEmptyPasswords is enabled), "password" and "publickey".
На большинстве серверов разрешены методы publickey,password,keyboard-interactive. В этом случае если публичный ключ клиента серверу неизвестен, то он перейдёт к следующему методу аутентификации и запросит пароль пользователя.
В Амазоне по умолчанию запрещены все методы кроме publickey. В этом случае если у пользователя нет ключа, который знает сервер, то сеанс создан не будет.
Пункты 4 и 5 вашего вопроса я не понял.
Насколько я понимаю, ssh, упрощено работает таким образом:
Всё не совсем так:
- Сначала Происходит обмен версиями серверов и поддержкой криптографических алгоритмов.
- Обмен ключами по схеме Диффи — Хеллмана. Не расписывая подробности, это генерирует общий секрет
Kдля обоих узлов. При этом используются только эфемерные ключи (т.е. те, которые используется только для получения общего секрета, а затем сразу уничтожаются) и не нужна отправка секрета по открытому каналу. - На основе секрета (
K), а также некоторых других данных, известных обеим сторонам генерируется сеансовый ключH, который сервер подписывает своим приватным ключом и отправляет эту подпись (HS) и свой публичный ключ клиенту. - Клиент проверяет публичный ключ сервера по своей базе или каким-либо другим способом, а также что
HSподписана именно ключом сервера и, если что-то пошло не так, то выводит сообщение и отключается.
Всё дальнейшее общение сервера и клиента шифруется ключом H (точнее прикладными симметричными ключами, полученными на его основе).
- Далее сервер предлагает клиенту методы аутентификации (в зависимости от настроек): по ключу, по паролю и т.п.
- Если клиент выбрал аутентификацию по ключу, то он отправляет свой публичный ключ, а также подписывает своё сообщение приватным ключом.
- Сервер проверяет подпись сообщения присланным публичным ключом, а также проверяет наличие этого ключа в своей базе данных (
authorized_keys) и принимает решение, разрешить соединение или нет. Если нет, то он может предложить другой метод аутентификации; например, по другому ключу или паролю.
т.е. есть следующие важные отличия:
- И пара ключей сервера (в
/etc/ssh/) и клиентская (в ~/.ssh/`) используется только для аутентификации и не используется для шифрования, как такового. - Для установки защищённого соединения используются прежде всего эфемерные ключи, сгенерированные в момент установки соединения и уничтожаемые сразу после этого.
- Пересылка секрета не происходит. Каждый узел генерирует его самостоятельно.
- Для своей аутентификации узел подписывает некую строку своим приватным ключом, а вторая сторона проверяет эту подпись. Проверка шифрования не происходит.
Полезные ссылки
- Неплохая статья по начальному рукопожатию ssh (перевод)
- RFC4552: Протокол аутентификации SSH.