ssh не вдається домовитись - не знайдено відповідного методу обміну ключами

Я намагаюсь увійти до свого маршрутизатора DSL, тому що у мене проблеми з поштою командного рядка. Я сподіваюся, що зможу переналаштувати маршрутизатор.

Коли я даю sshкоманду, ось що відбувається:

$ ssh enduser@10.255.252.1

Unable to negotiate with 10.255.252.1 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

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

$ ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 enduser@10.255.252.1

Unable to negotiate with 10.255.252.1 port 22: no matching cipher found. Their offer: 3des-cbc

так чи є команда запропонувати 3des-cbc шифрування? Я не впевнений у 3des, наприклад, чи хочу я його постійно додавати до своєї системи.

Чи є команда дозволити 3des-cbcшифр?

У чому тут проблема? Це не запит пароля.

Ця конкретна помилка трапляється під час налаштування зашифрованого каналу. Якщо ваша система та віддалена система не мають принаймні одного шифру, немає шифру, на який можна погодитись, і зашифрований канал неможливий. Зазвичай SSH-сервери пропонують невелику кількість різних шифрів для задоволення різних клієнтів; Я не впевнений, чому ваш сервер був би налаштований так, щоб дозволяти лише 3DES-CBC.

Тепер 3DES-CBC не страшний. Це повільно, він забезпечує менший захист, ніж деякі інші алгоритми, але він не одразу зламаний, якщо клавіші вибрані належним чином. У самій CBC є деякі проблеми, коли шифротекст може бути змінений під час транзиту, але я сильно підозрюю, що корупція в результаті буде відхилена HMAC SSH, зменшуючи вплив. Підсумок, є гірші варіанти, ніж 3DES-CBC, і є кращі. Однак завжди слід ретельно ступати, коли переосмислюються параметри, пов’язані із безпекою, включаючи вибір алгоритму обміну шифрами та ключами.Ці параметри за замовчуванням є причинами; деякі досить розумні люди витратили частину мозку на розгляд варіантів і визначили, що те, що було обрано за замовчуванням, забезпечує найкращу загальну безпеку порівняно з продуктивністю.

Як ви з’ясували, ви можете скористатися -c ...(або -oCiphers=...), щоб вказати, який шифр запропонувати від клієнта. У цьому випадку додавання -c 3des-cbcдозволяє лише 3DES-CBC від клієнта. Оскільки це відповідає шифру, який пропонує сервер, зашифрований канал може бути встановлений і з'єднання переходить до фази аутентифікації.

Ви також можете додати це до свого особистого ~/.ssh/config. Щоб уникнути глобальних змін для вирішення локальної проблеми, ви можете поставити її в Hostстрофу. Наприклад, якщо ваш конфігурація SSH в даний час говорить (фіктивний приклад):

Port 9922

задаючи глобальний порт за замовчуванням 9922 замість типового 22, ви можете додати хосту строфу для хоста, яка потребує спеціальної конфігурації, і глобальну строфу хоста для випадку за замовчуванням. Це стане щось на зразок ...

Host 10.255.252.1
    Ciphers 3des-cbc
    KexAlgorithms +diffie-hellman-group1-sha1
Host *
    Port 9922

Відступ необов’язковий, але я вважаю, що він значно покращує читабельність. Порожні рядки та рядки, що починаються з #, ігноруються.

Якщо ви завжди (або в основному) входите в систему як той самий користувач у цій системі, ви також можете вказати це ім’я користувача:

Host 10.255.252.1
    Ciphers 3des-cbc
    KexAlgorithms +diffie-hellman-group1-sha1
    User enduser
Host *
    Port 9922

Вам не потрібно додавати Host *строфу, якщо у вашому ~ / .ssh / config нічого не було для початку, як у цьому випадку будуть лише компільовані або загальносистемні параметри (як правило, з / etc / ssh / ssh_config) б / в.

У цей момент командний рядок ssh для підключення до цього хоста зводиться до просто

$ ssh 10.255.252.1

і всі інші користувачі вашої системи, а також з'єднання з усіма іншими хостами з вашої системи не впливають на зміни.

Добре, я прочитав сторінку і зрозумів це.

Я не хотів змінювати свій конфігураційний файл, і тому я шукав термін "шифр" на сторінці man, який показав мені -cможливість; це дозволяє мені вказати тип шифрування. тоді була завершена команда:

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -c 3des-cbc enduser@10.255.252.1

Нещодавно я зіткнувся з цією проблемою за допомогою PuTTY для підключення до нової версії Ubuntu. Здається, більш ранні версії PuTTY не мали оновлених шифрів. Тому завантаження останньої версії PuTTY виправило проблему. Це може бути іншим рішенням.

Ще одна відповідь для команд MacOSX та CLI (SFTP, наприклад): див. Цю статтю @ http://www.openssh.com/legacy.html (OpenSSL Legacy Options). Я отримував послідовну помилку "не вдалося домовитись", яка була вирішена інформацією в цій статті, зокрема встановленням параметра конфігурації у файлі "~ / .ssh / config".

До речі, я отримав цю помилку, коли мій SFTP-сервер призначення (не під моїм адміністрацією) остаточно відключив TLS 1.0 (опція шифрування SSL) і вимагає TLS 1.1 або 1.2.