1. Введение в протокол SSH
мы часто используемssh username@hostIpКоманда для входа на наш Linux-сервер, как показано на следующем рисунке:
Мы также понимаем, что это использует протокол SSH для входа в систему, но мы хотим знать, почему мы можем войти в систему, используя протокол SSH, и почему безопасно использовать SSH, и каков принцип, лежащий в основе этого? Давайте обсудим эти темы вместе.
конечно! Если у вас есть облачный хост, доступный из соответствующей общедоступной сети, войдите в свой облачный хост и выполнитеgrep sshd.*Failed /var/log/secureВзгляните на команду, вы можете быть удивлены, обнаружив, что существует много выходных журналов, и вы поймете, сколько людей пытается войти на ваш хост.
Проще говоря, протокол SSH — это протокол для удаленного безопасного входа в систему, созданный в небезопасной сети. Это семейство протоколов, которое имеет три подпротокола, а именно:
- 1. Протокол транспортного уровня
[SSH-TRANS]: Обеспечивает аутентификацию сервера, функции целостности и конфиденциальности, построенные на традиционном протоколе TCP/IP. - 2. Протокол аутентификации
[SSH-USERAUTH]: аутентификация пользователя клиента на сервере. Существует два метода аутентификации, основанные на имени пользователя, пароле и открытом ключе. Он основан на протоколе транспортного уровня.[SSH-TRANS]выше. - 3. Соглашение о подключении
[SSH-CONNECT]: Мультиплексировать зашифрованный туннель в несколько логических каналов. Он построен поверх протокола аутентификации.
Мы не будем давать здесь более подробное представление о протоколе SSH, мы можем его использовать Baidu сами. Следующие идеи для написания сначала проанализируют вышеупомянутые три процесса протокола SSH через захват пакетов wireshire и, наконец, обсудят проблемы, с которыми редактор столкнулся в течение всего процесса обучения.
Во-вторых, анализ процесса рукопожатия протокола SSH.
Прежде чем перейти к следующему, вот несколько очень важных концепций!
- 1,
会话密钥 keyКлюч: согласовывается между клиентом и сервером с помощью таких алгоритмов, как D-H. - 2,
公钥 pub key:pub ключ становится服务器主机密钥server_host_key, заSSH-TRANSПротокол передачи используется для проверки сервера, грубо говоря, он используется клиентом для проверки сервера.
Общий поток процесса рукопожатия протокола SSH показан на следующем рисунке:
Ниже приведен пакет данных, захваченный редактором через инструмент wireshire, давайте проанализируем его шаг за шагом:
- 1. Трехстороннее рукопожатие TCP для установления соединения
Все мы знаем, что в протоколе TCP есть процесс, называемый трехсторонним рукопожатием.Из приведенного выше рисунка видно, что серийный номер (647-649) — это процесс установления TCP-соединения.
| NO. | описывать | seq | Win | ACK | объяснять |
|---|---|---|---|---|---|
| 647 | первое рукопожатие | 0 | 8192 | никто | seq = 0 указывает текущий порядковый номер TCP-пакета клиента. |
| 648 | второе рукопожатие | 0 | 14600 | 1 | seq = 0, указывающий текущий порядковый номер пакета TCP на стороне сервера ack = 1 (client seq + 1), что означает ответ на клиентский seq = 0-й TCP-пакет |
| 649 | третье рукопожатие | 1 | 65536 | 1 | seq = 1, указывающий текущий порядковый номер TCP-пакета клиента ack = 1 (server seq + 1), что означает отвечать на TCP-пакет с seq = 0 на стороне сервера |
- 2. Обмен протоколами версии SSH
Серийный номер (647-649) на приведенном выше рисунке — это процесс обмена протоколом версии SSH.
| NO. | описывать | объяснять |
|---|---|---|
| 650 | Согласование версии протокола | Сервер отправляет клиенту собственную версию протокола SSH в формате:SSH-protoversion(版本号)-softwareversion(自定义) SP(空格一个,可选) comments(注释,可选) CR(回车) LF(换行)
|
| 651 | Согласование версии протокола | Клиент отправляет на сервер собственную версию протокола SSH в формате:SSH-protoversion(版本号)-softwareversion(自定义) SP(空格一个,可选) comments(注释,可选) CR(回车符) LF(换行符)
|
Этот шаг на самом деле ничего не нравится, это отправить форматSSH-protoversion-softwareversion SP comments CR LFтолько байтовый поток.
- 3. Ключевой ключ согласования
Серийный номер (652-677) на приведенном выше рисунке — это процесс обмена протоколом версии SSH.
Процесс согласования ключей отправляется клиентом и сервером друг другу.Key Exchange InitВ начале запроса основная цель — сообщить другой стороне список соответствующих алгоритмов шифрования и алгоритмов MAC, которые она поддерживает.
После успешного окончательного согласования будет сгенерировано симметричное шифрование.会话密钥keyи会话ID,Здесь следует подчеркнуть,что это симметричный ключ шифрования,не путать с открытым ключом.Разница между открытым ключом и ключом была подчеркнута в начале выше.Открытый ключ используется клиентом проверить сервер.
На этом этапе открытый ключ передается с сервера клиенту:
Сессионный ключ вычисляется по алгоритму DH и не передается по сети.Сложность его взлома зависит от сложности взлома дискретных логарифмов.Как правило, он не будет взломан.Кому интересно,может понять принцип работы алгоритм сами по себе.
Ниже я опубликуюKey Exchange InitАнализ данных отправленных пакетов запросов
| NO. | описывать | объяснять |
|---|---|---|
| 1 | kex_algorithms |
Алгоритм обмена ключами, который содержит используемый нами алгоритм D-H, используется для генерации сеансового ключа. |
| 2 | server_host_key_algorithms |
Алгоритм ключа хоста сервера, который может бытьssh-rsa,ssh-dss,ecdsa-sha2-nistp256, Существуют открытые ключи и закрытые ключи. Открытый ключ — это открытый ключ, о котором мы упоминали выше. Понятие открытого ключа и закрытого ключа см.understanding public key private key concepts
|
| 3 | encryption_algorithms_client_to_server |
Алгоритм симметричного шифрования, обычно используемыйaes128-cbc,3des-cbc
|
| 4 | mac_algorithms_client_to_server |
Алгоритм MAC, в основном используемый для обеспечения целостности данных |
| 5 | compression_algorithms_client_to_server |
алгоритм сжатия |
- 4. Этап сертификации
Серийный номер (678-680) на приведенном выше рисунке — это этап аутентификации версии SSH.
-
1. Аутентификация на основе учетной записи и пароля
Клиент будет владеть
用户名 + 密码сгенерировано с помощью вышеуказанного会话密钥keyПосле шифрования он отправляется на сервер для проверки. Если проверка сервера проходит, ответ считается успешным, в противном случае он будет повторно аутентифицирован ограниченное количество раз (рекомендуется 20 раз). Насчет того, как проверяется сервер, сочетается ли он с идентификатором сессии, редактору непонятно, да и в интернете есть разные мнения.
Обратите внимание, что имя пользователя и пароль предназначены для использования вышеуказанного ключа сеанса согласования ключа. Сгенерированный ключ зашифрован, включая сеанс подключения данных. Более поздние этапы передачи не считаются использованием шифрования открытого ключа сервера. -
2. Метод проверки на основе открытого ключа и закрытого ключа
Этот метод также называется входом без пароля. Проще говоря, клиент генерирует открытый ключ и закрытый ключ (обычно генерируется программой ssh-keygen), а затем каким-то образом сохраняет открытый ключ на сервере (обычно добавляется вручную).
~/.ssh/authorized_keysВ файле сервер примет открытый ключ, зашифрованный сеансовым ключом, отправленным клиентом в будущем, а затем расшифрует, чтобы получить открытый ключ и локальныйauthorized_keysРавны ли настроенные открытые ключи, если да, вход разрешен.
Если вы настроили публичный ключ github или gitlab, на самом деле, второй метод аутентификации очень прост для понимания, потому что github также использует протокол SSH для клонирования кода, и кажется, что клонирование не разрешено без настроенного публичного ключа .
3. Связанные вопросы
- 1. Безопасна ли фаза согласования ключей? Атаки «человек посередине» не существует!
Насколько я понимаю, первый раз всегда небезопасно. Зачем? Как было сказано выше, в процессе согласования сервер отправит собственный публичный ключserver_host_key_algorithmsОтправьте его клиенту, но клиент не может гарантировать, что открытый ключ, который он получает, отправлен целевым сервером.Вполне вероятно, что посредник перехватывает ваш запрос, а затем посредник отправляет вашему клиенту другой открытый ключ.Это небезопасно больше! Это также объясняет, почему при первом входе в систему терминал оболочки всегда показывает это приглашение:
Это также стратегия, которая оставляет право подтверждения на собственное суждение клиента. Напротив, если мы хотим быть более безопасными, мы можем использовать второй метод аутентификации для входа в систему. Поскольку подсказка является открытым ключом после MD5, как мы можем судить, что это значение допустимо? См. вопрос 3 ниже.
- 2. Какова функция ключа сеанса и идентификатора сеанса, согласованных транспортным протоколом?
Ключ сеанса: ключ алгоритма симметричного шифрования используется для шифрования и расшифровки данных связи.Идентификатор сеанса немного похож на сеанс в Интернете, который используется для представления каждого сеанса.В то же время он также используется чтобы судить, действителен ли тот же сеанс на этапе аутентификации.
- 3. Поскольку для входа в систему используется аутентификация по паролю, как проверить правильность открытого ключа сервера при первом входе клиента?
Скажите мне, пожалуйста! Я изо всех сил пытаюсь найти ответ!
4. Другое
Ниже приведены сопутствующие документы:
- 1,Адрес документа SSH RFC на китайском языке
- 2,The Secure Shell (SSH) Protocol Architecture
- 3.The Secure Shell (SSH) Transport Layer Protocol
Мы можем спросить, поскольку у нас есть документ протокола SSH, если мы хотим написать реализацию в соответствии с документом, с чего нам начать? Фактически транспортный протокол в SSH[SSH-TARNS]Он основан на протоколе TCP, поэтому мы можем начать с создания базового сокета Java Socket и постепенно внедрять протокол передачи SSH, протокол аутентификации и протокол подключения. Если вам интересен процесс внедрения, вы можете изучитьganymed-ssh2-build209.jarВ исходном коде протокола SSH в сочетании с RFC-документом протокола SSH вы обнаружите, что процесс согласования и аутентификации в протоколе SSH фактически реализован в виде входного и выходного потоков Socket. Сам редактор сдался на стадии переговоров, потому что слишком мало знал об алгоритме!