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

и все другие пользователи в вашей системе, а также соединения со всеми остальными хостами из вашей системы, не будут затронуты изменениями.

Хорошо, я прочитал справочную страницу и понял это.

Я не хотел изменять свой конфигурационный файл, и поэтому я искал термин «шифр» на странице руководства, который показал мне -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.