Bug 31716 - После обновления ssh перестал цепляться к Cisco
: После обновления ssh перестал цепляться к Cisco
Status: CLOSED NOTABUG
: Sisyphus
(All bugs in Sisyphus/openssh)
: unstable
: all Linux
: P3 major
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2016-01-19 08:31 by
Modified: 2016-01-25 23:16 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2016-01-19 08:31:03
К которой ранее цеплялся без проблем. Посколько каждый день с Cisco-ми работаю 
заметил сразу же. Выглядит так:
.... no matching key exchange method found. Their offer:
diffie-hellman-group1-sha1
   До этого такого не было. Ну, не цепляться же telnet-ом по незащищённому
каналу!
Где версия IOS поновее туда и не идёт. Поскольку сеть большая - напряжно.
   А вот как выгляди, если запустить ssh с ключом -v:
OpenSSH_7.1p1, OpenSSL 1.0.2e 3 Dec 2015
debug1: Reading configuration data /etc/openssh/ssh_config
debug1: /etc/openssh/ssh_config line 20: Applying options for *
debug1: Connecting to 10.135.63.12 [10.135.63.12] port 22.
debug1: Connection established.
debug1: identity file /home/-----/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/-----/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/-----/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/-----/.ssh/id_dsa-cert type -1
debug1: identity file /home/-----/.ssh/id_ecdsa type 3
debug1: key_load_public: No such file or directory
debug1: identity file /home/-----/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/-----/.ssh/id_ed25519 type 4
debug1: key_load_public: No such file or directory
debug1: identity file /home/-----/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.1
debug1: Remote protocol version 1.99, remote software version Cisco-1.25
debug1: match: Cisco-1.25 pat Cisco-1.* compat 0x60000000
debug1: Authenticating to 10.135.63.12:22 as '-----'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes256-cbc hmac-sha1 none
debug1: kex: client->server aes256-cbc hmac-sha1 none
ssh: Unable to negotiate with 10.135.63.12: no matching key exchange method
found. Their offer: diffie-hellman-group1-sha1

     Заметим: файл id_rsa есть, id_rsa.pub тоже есть. Специально для проверки
сгенерировал id_ecdsa и id_ed25519. Та же жопа, только с другого бока!
     До обновления всё работало тики-тики!

P.S. на ----- внимания не обращайте!
------- Comment #1 From 2016-01-19 09:39:01 -------
тут всё рассказано:
http://www.openssh.com/legacy.html
------- Comment #2 From 2016-01-19 11:10:03 -------
(In reply to comment #0)
> ssh: Unable to negotiate with 10.135.63.12: no matching key exchange method
> found. Their offer: diffie-hellman-group1-sha1

Тут же всё цветом по фону написано -- сервер предлагает всего один key exchange
method, клиент не хочет с ним работать.

Напишите в конфиг про этот хост
 KexAlgorithms +diffie-hellman-group1-sha1
Этот алгоритм теперь в ssh-клиенте по-умолчанию выключен.
------- Comment #3 From 2016-01-20 12:00:18 -------
Коллеги, а как думаете, в rescue iso стоит разрешить diffie-hellman-group1-sha1
и ssh-dss?
------- Comment #4 From 2016-01-20 12:04:37 -------
в rescue ssh не критичен, а кому нужен - тот и сам знает.
------- Comment #5 From 2016-01-20 12:16:27 -------
Я думаю, что в (потенциально стрессовых) условиях использования rescue не
каждый навскидку вспомнит список изменений в openssh, поэтому я за то, чтобы
разрешить.
------- Comment #6 From 2016-01-20 12:18:26 -------
Конечно, от того, что разрешишь - ничто нигде не сломается ;)
Но сколько себя помню - не приходилось из rescue ходить по ssh, разве что из
чрута установленной системы, а там уже всё и так было настроено.
------- Comment #7 From 2016-01-20 13:21:17 -------
(В ответ на комментарий №6)
> Но сколько себя помню - не приходилось из rescue ходить по ssh
Мне регулярно доводится вытаскивать данные наружу или, наоборот, затягивать.
В общем, постараюсь включить, т.к. согласен со мнением evg@.
------- Comment #8 From 2016-01-21 09:22:19 -------
Ребята! РАЗРЕШАЙТЕ! В реале приходилось ходить из rescue ALTLinux по ssh!
Залетели диски и доступа к другой тачке не было - пришлось запускаться с DVD и
лезть управлять Cisco с rescue! Там ещё хуже ситуация была, было не до
восстановления своей тачки было - там почти вся сеть лежала! А это не много и
не мало порядка 60 Cisco и 20 офисов в пяти областях.
------- Comment #9 From 2016-01-21 09:24:21 -------
Спасибо, тебе, glebfm! Твой совет оказался лучше всего! Опубликуйте его ещё и в
документации - там ничего об этом нет. Только на сайте. А до сайта не всегда,
как показывает практика, и долезть можно.
------- Comment #10 From 2016-01-25 23:16:47 -------
(В ответ на комментарий №8)
> Ребята! РАЗРЕШАЙТЕ! В реале приходилось ходить из rescue ALTLinux по ssh!
Сделано в mkimage-profiles 1.1.83 -- соответственно в регулярках этой недели
тоже должно быть учтено.