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

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

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

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

— DW
источник

Dupe of superuser.com/questions/962918/… и (кросс) unix.stackexchange.com/questions/247612/…

— dave_thompson_085

Спасибо, @ 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

Ответы:

Это результат обновления до 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
источник

Выбор типа ключа обсуждается в разделе Безопасность в течение некоторого времени. Безопасность ключей DSA сомнительна с самого начала и менее надежна, если у вас нет хорошего генератора случайных чисел (в котором вы не можете быть уверены). И поскольку теперь есть другие возможные типы ключей, нет никаких оснований сохранять сомнительные.

— Jakuje

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

— DW

Смотрите здесь для более подробного обсуждения.

— DW

Мои два цента

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

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

Затем скопируйте новый открытый ключ (в клипборд)
Войдите в последний раз , используя старый ключ:
```
ssh -i .ssh/id_dsa.pub -o PubkeyAcceptedKeyTypes=+ssh-dss user@host
```
Затем обновить @host«s authorized_keysфайл, добавив свой новый Публичный и выход из системы
```
cat >>.ssh/authorized_keys
```
pasteтогда Ctrl+D
Войдите с новым ключом, используя синтаксис по умолчанию:
```
ssh user@host
```
1. Затем обновить @host«s authorized_keysфайл, по удалению старого Публичных (я использую , sed -e 1d -i .ssh/authorized_keysкогда мой старый Публичных на линии 1этого файла).
2. Я предлагаю обновить ваш SSH сервер, если вы можете.
3. выйти
Проверьте, не работает ли старый ключ больше.
```
ssh -i .ssh/id_dsa.pub -o PubkeyAcceptedKeyTypes=+ssh-dss user@host
...
Permission denied...
```
Это должно не работать ;-)
Вы могли бы даже перепроверить, все ли в порядке:
```
ssh user@host uptime
```

— Ф. Хаури
источник

Для меня не очевидно, почему вы думаете, что редактирование ~/.ssh/configне такая хорошая идея.

— DW

Потому что это устарело и автор ssh рекомендует не использовать. См. Openssh.com/legacy.html

— Ф. Хаури

О, я понимаю. Похоже, ваше беспокойство связано не с идеей редактирования ~/.ssh/configкак таковой, а с идеей разрешения DSA. Спасибо за объяснение. В этом есть смысл. (Я думаю, что я уже рассмотрел в своем ответе и моих комментариях, почему я нахожу эту рекомендацию озадачивающей, но я не буду пытаться обсуждать это здесь.)

— DW

Редактирование позволяет .configвам выполнять sshв течение длительного времени и даже запотеть, что вы используете слабый алгоритм. Используя -o Pubkey...в командной строке, вы не простите, что есть что обновить .

— Ф. Хаури