Иногда такое случается - речь о заголовке заметки. SSH Algorithm Negotiation Fail - сообщение о том, что клиент и сервер SSH не смогли договориться об алгоритме, который они будут использовать для шифрования.
Ошибка проявляется при:
- Использовании устаревшего клиента SSH
- Использований всяких экзотических реализаций (типа .NET или Java) - так, например масса приложений в Windows Store для “таблетов” и телефонов завязаны на одну и ту же .Net библиотеку (однако, исправно просят денег)
- Внезапном апгрейде серверной части
- Общей паранойей администратора
На самом деле - ситуация вполне нормальная, и более того - это “для вашей же безопасности” - в современных дистрибутивах Linux ssh по умолчанию использует только “хорошие” алгоритмы.
Выход - обновить ваш клиент. Но, бывают ситуации, когда “быстрый”, но менее надежных шифр нужен (особенно если идёт возня с embedded, где каждый тик процессора на счету).
Ну, или например poor unfortunate souls - владельцы Windows Phone (вроде меня) хотят пользоваться ssh-доступом к серверу, а тут такой облом.
Короче, выход есть, правда придется пожертвовать некоторым количеством безопасности и прокачать паранойю до 80го уровня.
- Шаг первый - получим список всех доступных шифров
Для этого нужно быть в консоли, то есть наступить на горло собственной песне и всё-таки запустить каноничный Putty.
Выполним такую команду:
ssh -Q cipher localhost | paste -d , -s
Ответ системы примерно такой:
3des-cbc,blowfish-cbc,cast128-cbc,arcfour,arcfour128,arcfour256,aes128-cbc,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
- Шаг второй - обновим конфигурацию ssh
В /etc/ssh/sshd_config в самый конец добавим слово “Ciphers”, а после него просто скопируем текст полученный на первом шаге.
Ciphers 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,arcfour128,arcfour256,aes128-cbc,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
- Шаг третий - нужно пере запустить сервис ssh
Тут зависит от вашего дистрибутива - в общем случае - /etc/init.d/ssh restart под рутом.
Не торопитесь закрывать окно - откройте ещё одну сессию и убедитесь, что соединения продолжают работать.
Ещё раз - это действие не решение проблемы, а workaround. Так что подумайте хорошо, может имеет смысл всё-таки сменить клиентскую часть :)