Безопасное сетевое взаимодействие (часть 3)

Метод аутентификации с использованием открытого ключа: publickey

Единственным обязательным методом аутентификации является аутентификация с использованием открытого ключа. Все реализации должны поддерживать этот метод. Однако не все пользователи имеют открытые ключи, и большинство локальных политик, вероятно, не будут требовать в ближайшем будущем обязательной аутентификации с использованием открытого ключа.

При использовании данного метода посылается подпись, созданная закрытым ключом пользователя. Сервер должен убедиться, что открытый ключ данного пользователя является действительным, и проверить, что подпись правильна. Если оба этих условия выполняются, запрос аутентификации должен считаться выполненным; в противном случае он должен быть отвергнут. Заметим, что сервер может потребовать дополнительные аутентификации после успешного завершения данной аутентификации.

Закрытые ключи на хосте клиента часто хранятся в зашифрованном виде, и пользователь должен ввести парольную фразу перед созданием подписи. Операция подписывания означает достаточно большую вычислительную нагрузку. Чтобы избежать лишних вычислений и взаимодействия с пользователем, применяется следующее сообщение для запроса, может ли приниматься аутентификация с использованием ключа.

SSH_MSG_USERAUTH_REQUEST
имя пользователя
сервис
"publickey"
FALSE
имя алгоритма открытого ключа
public key blob

Алгоритмы открытого ключа определены в спецификации транспортного уровня. Public key blob может содержать сертификаты.

Любой алгоритм открытого ключа из данного списка может использоваться для аутентификации. Подобный список не является обязательным при переговорах об обмене ключа, но он влияет на то, для каких алгоритмов сервер имеет открытый ключ. Если сервер не поддерживает некоторый алгоритм, он должен просто отвергнуть запрос.

Сервер должен ответить на данное сообщение либо SSH_MSG_USERAUTH_FAILURE, либо

SSH_MSG_USERAUTH_PK_OK
имя алгоритма открытого ключа из запроса
public key blob из запроса

Для того чтобы реально пройти аутентификацию, клиент должен затем послать подпись, созданную с использованием своего закрытого ключа. Клиент может послать подпись непосредственно, без начальной проверки, принимаем ли ключ. Подпись посылается в следующем пакете:

SSH_MSG_USERAUTH_REQUEST
имя пользователя
сервис
"publickey"
TRUE
имя алгоритма открытого ключа
открытый ключ, используемый для аутентификации
подпись

Подпись осуществляется для данных в следующем порядке:

• Идентификатор сессии;
• Содержимое пакета без подписи.

Когда сервер получает данное сообщение, он должен убедиться, что предложенный ключ принимается для аутентификации, и после этого проверить корректность подписи.

Если обе проверки проходят, то данный метод считается успешным. Сервер может потребовать дополнительной аутентификации. Сервер должен ответить сообщением SSH_MSG_USERAUTH_SUCCESS, если больше никаких аутентификаций не требуется, или сообщением SSH_MSG_USERAUTH_FAILURE, если проверки не прошли или необходимы дополнительные аутентификации.

Метод аутентификации с использованием пароля: password

При аутентификации с использованием пароля посылаются следующие пакеты. Сервер может потребовать от пользователя изменить пароль. Все реализации должны поддерживать аутентификацию паролем.

SSH_MSG_USERAUTH_REQUEST
имя пользователя
сервис
"password"
FALSE
незашифрованый пароль

Для пароля применяется кодировка ISO-10646 UTF-8. Сервер сам решает, как интерпретировать пароль и как проверять его законность в базе данных паролей. Однако если пользователь вводит пароль в некоторой другой кодировке, клиентское ПО должно перед пересылкой преобразовать пароль в кодировку ISO-10646 UTF-8; сервер должен преобразовать пароль в кодировку, используемую в данной системе для хранения паролей.

Пароль передается в пакете в незашифрованном виде, но весь пакет шифруется на транспортном уровне, тем самым пароль защищен от просматривания и модификации. И сервер, и клиент должны проверять, обеспечивает ли нижний транспортный уровень конфиденциальность, т.е. используется ли шифрование. Если конфиденциальность не обеспечивается ( none шифратор), аутентификация паролем должна быть запрещена. Если нет конфиденциальности или МАС, то изменение пароля должно быть запрещено.

Обычно сервер отвечает на данное сообщение сообщением об успехе или неудачном выполнении аутентификации. Однако сервер может ответить и сообщением SSH_MSG_USERAUTH_PASSWD_CHANGEREQ.

SSH_MSG_USERAUTH_PASSWD_CHANGEREQ
приглашение (ISO-10646 UTF-8)
тег языка

В этом случае клиентское ПО должно запросить у пользователя новый пароль и послать новый запрос с использованием следующего сообщения. Клиент также может послать это сообщение вместо обычного запроса аутентификации паролем без соответствующего требования со стороны сервера.

SSH_MSG_USERAUTH_REQUEST
имя пользователя
сервис
"password"
TRUE
незашифрованный старый пароль (ISO-10646 UTF-8)
незашифрованный новый пароль (ISO-10646 UTF-8)

Сервер должен ответить на это сообщение сообщениями SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, или другим сообщением SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. Эти ответы имеют следующий смысл:

SSH_MSG_USERAUTH_SUCCESS
Пароль изменен и аутентификация успешно 
выполнена.
SSH_MSG_USERAUTH_FAILURE с частичным успехом
Пароль изменен, но необходимы дополнительные
аутентификации.
SSH_MSG_USERAUTH_FAILURE без частичного успеха

Пароль не изменен. Это означает, что либо изменение пароля не поддерживается, либо старый пароль – неправильный. Заметим, что если сервер уже послал SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, то известно, что он поддерживает изменение пароля.

SSH_MSG_USERAUTH_CHANGEREQ

Пароль не изменен, потому что новый пароль не принимается, например, слишком прост для разгадывания.