SSH DSA ключи больше не работают для аутентификации без пароля

25

После обновления до Fedora 23 аутентификация без пароля (на основе открытого ключа) больше не работает в SSH: при попытке SSH к некоторому хосту он запрашивает мой пароль на удаленном хосте. Я не могу заставить его использовать мой закрытый ключ SSH. Все работало нормально с Fedora 22.

Мой открытый ключ - это ключ DSA ( ~/.ssh/id_dsa.pub). Я использую OpenSSH 7.1 ( openssh-7.1p1-5.fc23.x86_64).

Как я могу заставить аутентификацию без пароля снова работать правильно?

DW
источник
1
Спасибо, @ dave_thompson_085. Это не дурак из superuser.com/q/962918/93541 . Этот вопрос спрашивает, как использовать ssh -Q. Это спрашивает, как устранить проблему отказа SSH. Я нашел некоторые материалы на сайте superuser.com/q/962918/93541 и в других местах, полезные для определения этого решения, но в ответе описывается, как его использовать, ssh -Qи он не отвечает на этот вопрос (например, он не объясняет, как исправить это проблема), поэтому на мой взгляд это не дуп. Один на Unix и Linux является очень похожи; Хотел бы я видеть это раньше. Еще раз спасибо за ссылки!
DW
Ок, ты прав. Я пометил их обоих как «OpenSSH 7.0 no DSA», что в первом случае недостаточно близко. Сожалею.
dave_thompson_085

Ответы:

40

Это результат обновления до OpenSSH 7.0. Как сказано в примечаниях к выпуску OpenSSH 7.0 , «поддержка хоста и пользовательских ключей ssh-dss по умолчанию отключена во время выполнения».

Решение состоит в том, чтобы добавить следующую строку ~/.ssh/configна каждом клиентском компьютере (на каждом компьютере, на котором вы запускаете SSH-клиент):

PubkeyAcceptedKeyTypes=+ssh-dss

Если сервер использует OpenSSH 7.0 или новее, вам также необходимо добавить эту строку /etc/ssh/sshd_configна каждом сервере.

Кроме того, вы можете сгенерировать совершенно новый ключ SSH и добавить его в свой файл author_keys на каждом сервере, на котором вы когда-либо захотите войти. Я рекомендую вам использовать RSA , чтобы избежать проблем совместимости. Я не рекомендую ECDSA, так как, очевидно, gnome-keyring-daemon автоматически не получает ключи SSH типа ECDSA.


Редколлегия: Почему люди OpenSSH отключили ключи DSA? Я не знаю. Насколько я могу убедиться, нет ничего плохого в безопасности ключей DSA (ssh-dss). На веб-странице OpenSSH утверждается, что ssh-dss является слабым, но, насколько я знаю, 1024-битный ssh-dss не слабее 1024-битного RSA, и 1024-битные ключи RSA не отключены.

DW
источник
1
Выбор типа ключа обсуждается в разделе Безопасность в течение некоторого времени. Безопасность ключей DSA сомнительна с самого начала и менее надежна, если у вас нет хорошего генератора случайных чисел (в котором вы не можете быть уверены). И поскольку теперь есть другие возможные типы ключей, нет никаких оснований сохранять сомнительные.
Jakuje
2
@Jakuje, да, выбор типа ключа обсуждается в области информационной безопасности здесь и здесь . Я прочитал все это перед тем, как написать свое редакционное замечание, и меня все еще удивляет, почему ключи DSA были отключены: они не слабее, чем ключи RSA той же длины, которые не были отключены. Ни в одном из этих потоков нет ничего, что указывало бы на то, что DSA является «сомнительным», и, как говорит Томас Порнин, «нет никаких причин, связанных с безопасностью, чтобы отдавать предпочтение одному типу по сравнению с другим, предполагая достаточно большие ключи». (продолжение)
DW
Смотрите здесь для более подробного обсуждения.
DW
0

Мои два цента

Как редактирование .ssh/configфайла, чтобы разрешить это, кажется, не очень хорошая идея, я предлагаю

  1. Создайте новый ключ, используя недавний инструмент.

    Затем скопируйте новый открытый ключ (в клипборд)

  2. Войдите в последний раз , используя старый ключ:

    ssh -i .ssh/id_dsa.pub -o PubkeyAcceptedKeyTypes=+ssh-dss user@host
    

    Затем обновить @host«s authorized_keysфайл, добавив свой новый Публичный и выход из системы

    cat >>.ssh/authorized_keys
    

    pasteтогда Ctrl+D

  3. Войдите с новым ключом, используя синтаксис по умолчанию:

    ssh user@host
    
    1. Затем обновить @host«s authorized_keysфайл, по удалению старого Публичных (я использую , sed -e 1d -i .ssh/authorized_keysкогда мой старый Публичных на линии 1этого файла).

    2. Я предлагаю обновить ваш SSH сервер, если вы можете.

    3. выйти
  4. Проверьте, не работает ли старый ключ больше.

    ssh -i .ssh/id_dsa.pub -o PubkeyAcceptedKeyTypes=+ssh-dss user@host
    ...
    Permission denied...
    

    Это должно не работать ;-)

  5. Вы могли бы даже перепроверить, все ли в порядке:

    ssh user@host uptime
    
Ф. Хаури
источник
Для меня не очевидно, почему вы думаете, что редактирование ~/.ssh/configне такая хорошая идея.
DW
Потому что это устарело и автор ssh рекомендует не использовать. См. Openssh.com/legacy.html
Ф. Хаури
О, я понимаю. Похоже, ваше беспокойство связано не с идеей редактирования ~/.ssh/configкак таковой, а с идеей разрешения DSA. Спасибо за объяснение. В этом есть смысл. (Я думаю, что я уже рассмотрел в своем ответе и моих комментариях, почему я нахожу эту рекомендацию озадачивающей, но я не буду пытаться обсуждать это здесь.)
DW
Редактирование позволяет .configвам выполнять sshв течение длительного времени и даже запотеть, что вы используете слабый алгоритм. Используя -o Pubkey...в командной строке, вы не простите, что есть что обновить .
Ф. Хаури