Я использую аутентификацию с открытым ключом с secureCRT для входа на сервер Linux и отключения аутентификации по паролю на этих серверах:
1. Создайте пару ключей (формат ключа openssh) с помощью SecureCRT.
2. Добавьте открытый ключ с именем identity.pub в $ HOME / .ssh / authorized_keys.
3. в SSH2 категория Параметры сеанса сервера выберите PublicKey вариант в Аутентификация раздел, затем нажмите Свойства кнопку в Свойства диалоговом окне выберите Использовать настройку открытого ключа сеанса , затем найдите Использовать файл удостоверения или сертификата раздел и нажмите кнопку обозревателя файлов (…), затем я выбираю закрытый ключ с именем identity.
4. затем я могу войти на этот сервер, используя SecureCRT и введя пароль пары ключей, и все в порядке.
НО:
На другом сервере все то же самое на сервере. Но в SecureCRT вместо выбора закрытого ключа с именем identity, Я вместо этого выбрал общественный ключ назван identity.pub. Несмотря на это, я все еще мог войти в систему таким же образом.
Я не понимаю, как это возможно.
Право secureCRT использовать закрытый ключ для сопоставления открытого ключа на сервере? это ?
Вы должны распространить открытый ключ на серверы, на которые вы хотите войти (файл .pub), и сохранить частную часть в клиенте, с которого вы хотите вести журнал (сохраните файл pub там же, он вам понадобится в будущем для регистрации другого сервер).
На Linux-машине с openssh вы можете использовать ssh-copy-id -i keyfile.pub user@server распространять паб-часть ключа на серверы.
Если я правильно понимаю ваш вопрос, тогда да - вы должны указать SecureCRT использовать закрытый ключ, а не открытый ключ. Затем, когда вы заходите в систему, происходит следующее:
Ваш клиент (в данном случае SecureCRT) устанавливает соединение с сервером и говорит: «Эй, я хочу войти в систему как пользователь glancesx».
Сервер говорит: «Конечно, если вы докажете мне, что вы действительно glancesx». Вот набор данных («проблема»), которые я хочу, чтобы вы зашифровали и отправили мне с ключом, который я могу проверить.
Клиент использует закрытый ключ для математической подписи запроса и отправляет его обратно на сервер.
Сервер говорит: «Спасибо; позвольте мне проверить файл authorized_keys на наличие glancesx, чтобы узнать, использовали ли вы ключ, которому glancesx хочет, чтобы я доверял». Если он обнаружит какой-либо ключ, который соответствует зашифрованным данным, которые вы отправили обратно, вам будет разрешено войти.
Так что все дело в том, что там должен быть двумя частями ключа - одна на стороне клиента («identity»), а вторая - на стороне сервера («identity.pub»). Данные, подписанные одним, можно сверить с другим.