Аутентификация SSH открытым ключом и паролем в то же время

olcDatabase={0}bdb,cn=config

потребности, которые будут изменены на

olcDatabase={2}bdb,cn=config

0
10.01.2017, 14:03
2 ответа

OpenSSH 6.2 представленный несколько методов аутентификации.

Для ссылок см. sshd_config (5).

1
28.01.2020, 02:53
  • 1
    Затем, если они хотят обе аутентификации, у них должна быть (по крайней мере), эта версия sshd на стороне сервера, правильно? –  рüффп 07.11.2013, 17:21

Обычно, если Вы используете PublicKey и Password это - падение назад. PublicKey попробован сначала, потому что это более безопасно и более безопасно, затем Password предпринят.

Я СИЛЬНО (и я не могу сделать это достаточно полужирным). Предложите, чтобы Вы позволили только PublicKey основанная аутентификация для любых серверов SSH, что у Вас есть работа Интернета.

Когда соединение SSH устанавливается с помощью Password аутентификация пароль отправляется на сервер. Аутентификация по паролю оставляет Вас широко открытыми для обычного маршрута скота, вызывающего пароль. Который может и происходить, если будет достаточно пользователей, использующих, которые видят сервер (то один из них выберет дрянной пароль).

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

Тем не менее ключи могут быть зашифрованы с паролями. Таким образом, ключ, который Вы генерируете на своей локальной машине, может иметь (и делает по умолчанию), пароль для дешифрования его. Подразумевая, что Ваша локальная машина попросит у Вас пароля, дешифруйте свой ключ, отправьте ее на сервер, и сервер попытается пройти проверку подлинности. (Честно это действительно не дешифрует Ваш ключ, случается так, что открытый ключ "смещается" Вашим паролем).

Так, Если Вы используете PublicKey затем необходимо будет предоставить открытый ключ комбинации пользователя/машины попытка соединиться с.

Если Вы используете Password затем необходимо будет обеспечить, пароль (представил ясное) к серверу попытка соединиться с.

Если Вы используете PublicKey и Password затем необходимо будет обеспечить Или открытый ключ или пароль.

0
28.01.2020, 02:53
  • 1
    Вы могли бы хотеть перепроверить "в ясном" операторе. RFC 4253 (среди других) указывает, что эти две системы, вовлеченные в соединение SSH сначала, обмениваются идентификационными строками. Сразу впоследствии они обмениваются ключами и алгоритмом шифрования, и ключ будет согласован во время ключевого обмена. Когда шифрование в действительности, все полезные нагрузки пакета должны быть зашифрованы. Все это происходит, прежде чем Вы когда-либо будете видеть вход в систему: подсказка. –  doneal24 07.11.2013, 19:36
  • 2
    Вы корректны, обновляя ответ. –  coteyr 07.11.2013, 19:57
  • 3
    "Я СИЛЬНО (и я не могу сделать это достаточно полужирным). Предложите, чтобы Вы позволили только основанную на PublicKey аутентификацию для любых ssh серверов, что у Вас есть работа Интернета".->, к сожалению, это не моя обязанность выбрать, какой метод, это - внешние поставщики SFTP, кто выбирает то, что является лучшим для них, и мы должны соответствовать их выбору. У некоторых поставщиков также есть правила брандмауэра включить только наш (и другие авторизовали компании), IP. –  рüффп 08.11.2013, 10:55
  • 4
    "Так ключ, который Вы генерируете на своей локальной машине, может иметь (и делает по умолчанию), пароль к ветхому это"-> я предполагаю, что Вы говорите о пароле здесь. Я сделал различие между паролем (для соединения с удаленным сервером) и пароль (для включения ключевого извлечения). –  рüффп 08.11.2013, 10:57

Теги

Похожие вопросы