OpenSSH: авторизація на основі ключа, максимальна довжина ключа


9

Я використовую Putty у Windows з аутентифікацією на основі ключів для доступу до деяких шахтних серверів.

Він працює чудово з ~ 3700-бітним ключем, але з ~ 17000-бітним ключем він думає приблизно 20 секунд на стороні клієнта, а потім просто каже "Доступ заборонено" і запитує пароль.

Чи є обмеження довжини ключа або час очікування у OpenSSH для аутентифікації на основі ключів?

Я розумію, що використання таких великих клавіш не має особливого практичного сенсу, особливо, дивлячись на ці 20 секунд обчислення, просто намагаючись вирішити будь-які проблеми, з якими я стикаюся: -) ...


Я бачив подібні проблеми, що трапляються на деяких версіях OpenSSH, над якими я працював, використовуючи довжину ключа потужністю два.
kasperd

Відповіді:


9

Якось я заглянув у джерело OpenSSL для ключів Diffie-Hellman, і виявив, що існує "довільне" обмеження 10K щодо розміру ключів DH. Я змінив джерело для тестування і виявив, що це спрацювало. Я написав помилку авторам, і вони відповіли, що це було задумом запобігти DoS за допомогою масивних клавіш.

Не здивував би мене те, що побачив щось подібне у OpenSSH.


5

У протоколі не визначено максимального розміру або тайм-ауту (або принаймні жодного, який би ви потрапляли), але реалізація може не підтримувати такі довгі клавіші. 20-секундний час обробки за допомогою приватного ключа не є високим для 17-бітового ключа RSA. Тоді сервер може не захотіти витрачати занадто багато обчислювальної потужності на неавторизованого користувача: відмова від дуже великих клавіш - це захист від DoS-атак.

В даний час 2048 біт вважається розумним для ключа RSA; 4096 біт вище, ніж потрібно, але зазвичай підтримується; Крім цього, ви не повинні дивуватися, якщо деякі програми відхиляють ключ.


Цей захист виглядає розумним. Це можна настроїти чи жорстко закодувати у вихідному коді?
BarsMonster

У цьому посібнику немає цього варіанту, тому будь-яке обмеження має бути у вихідному коді. Однак, я не знаю, чи є захист насправді, я просто мав на увазі, що розумно мати його. Я підозрюю, що відповідь AndreasM ближче до позначки.
Жил 'ТАК - перестань бути злим'

4

Чи змогли ви створити такий розмір ключа в цільовій цільовій системі? Можливо, ви маєте обмеження на те, що підтримується. Швидше поточна система Centos шахти підтримує максимум 16 кб, що здається достатнім для масивних клавіш. Ви повинні побачити максимум, якщо спробуєте перейти над ним за допомогою ssh-keygen, як показано нижче.

[nathan@omni ~]# ssh-keygen -t rsa -b 32768
key bits exceeds maximum 16384

Те саме на Debian 8.2. Моя нетбук може витратити досить довго на створення цього 16384-бітного ключа ... те, що я роблю для сміху.
підкреслюй_d

Те саме на "Git Bash" для Windows 7, яка базується на MinGW.
користувач1364368

Те ж саме на OpenSuse Leap 42.1.
користувач1364368

2

На сервері Opensh є налаштування LoginGraceTime. На чоловіковій сторінці:

The server disconnects after this time if the user has not suc-
cessfully logged in.  If the value is 0, there is no time limit.
The default is 120 seconds.

Це може бути обмеженням, до якого ви потрапляєте, якщо він встановлений на 20 секунд.

Дивна здогадка: Можливо також, що сама шпаклівка має цю межу, думаючи, що якщо обробка автентифікацією відкритого ключа на стороні клієнта займе так довго, щось не так.


Я подумав те саме, і встановив LoginGraceTime 1200 Ну, повідомлення про помилку є в консолі, тому я сумніваюся, що це щось у Putty ...
BarsMonster

1
Перевірте журнали сервера. При такому розмірі ключа я отримую: RSA_public_decrypt не вдалося: помилка: 04067069: lib (4): func (103): причина (105). (очевидно, через розмір ключа.) Я спробую клавішу 2 ^ n.
AndreasM

1
16384 біт, здається, працює. Результати з 32 кбітами дивіться hermann-uwe.de/blog/… :)
AndreasM

1
Ви смертельно правильні: Знайдено thid: sshd [1014]: error: RSA_public_decrypt failed: error: 04067069: lib (4): func (103): reason (105) Отже, це має бути помилка в sshd / OpenSSL :-)
BarsMonster
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.