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/… та (cross) 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 та додати його до свого файла авторизованих ключів на кожному сервері, на якому ви хочете увійти. Я рекомендую вам використовувати RSA , щоб уникнути неприємностей щодо сумісності. Я не рекомендую ECDSA, оскільки, очевидно, gnome-keyring-демон не автоматично підбирає SSH ключі типу ECDSA.

Зауваження до редакції: Чому люди OpenSSH відключили ключі DSA? Не знаю. Наскільки я можу констатувати, у безпеці ключів DSA (ssh-dss) немає нічого поганого. На веб - сторінці OpenSSH стверджує , що SSH-СППР слабкий, але, наскільки мені відомо, 1024-бітний SSH-ДСС не слабкіше , ніж 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...в командному рядку, ви не пробачите, що є що оновити .

— Ф. Хаурі