Cisco ssh connection aborted error status 0

Сегодня наткнулся на довольно странную и неоднозначную проблему.

При подключении по SSH с одного маршрутизатора Cisco на другой получал многообещающий ответ:

c2811-01#ssh 172.16.11.76        
[Connection to 172.16.11.76 aborted: error status 0]

Причем подобное сообщение получал и при попытке обратного подключения.

Гугл навел на команду дебага:

c2811-01##debug ip ssh client 
SSH Client debugging is on

Повторяю попытку подключения:

c2811-01#ssh 172.16.11.76    
[Connection to 172.16.11.76 aborted: error status 0]
c2811-01#
Jan  7 11:51:52.454 MSK: SSH CLIENT0: protocol version id is - SSH-1.5-Cisco-1.25
Jan  7 11:51:52.454 MSK: SSH CLIENT0: protocol version exchange failure (code = 1)
Jan  7 11:51:52.458 MSK: SSH CLIENT0: Session disconnected - error 0x00

Далее поиск по фразе «SSH CLIENT0: protocol version exchange failure (code = 1)» дал понять что проблема может крыться в разнице используемых версий протокола SSH и/или первоначальном обмене ключами.

Выяснилось, что на одном из роутеров я забыл поменять версию протокола SSH на v2.
Смена версии также потребовала увеличения длинны ключа.
После перегенерации ключа длинной более 768 бит соединение устанавливается без проблем.

Running into two separate but probably similar issues.

First issue —

I have two Cisco 2900 Series routers on firmware v15.2(4)M4 trying to ssh into a Dell 5548P stack on firmware v4.1.0.8. All attempts fail instantly with —

router#ssh 1.2.3.4
[Connection to 1.2.3.4 aborted: error status 0]

Buffer log shows —

SSH2 CLIENT 0: Server has chosen 2056 -bit dh keys
%SSH-3-INV_MOD: Invalid modulus length

If I try to modify the DH key length on the router, attempts still fail and buffer log shows —

SSH2 CLIENT 0: Server has chosen 2056 -bit dh keys
%SSH-3-INV_MOD: Invalid modulus length  
%SSH-3-DH_RANGE_FAIL: Client DH key range mismatch with maximum configured DH key on server

SSH config on router —

SSH Enabled - version 2.0
Authentication timeout: 120 secs; Authentication retries: 3
Minimum expected Diffie Hellman key size : 1024 bits
IOS Keys in SECSH format(ssh-rsa, base64 encoded):
ssh-rsa keystringgoeshere

SSH config on 5548P stack —

SSH Server enabled. Port: 22
RSA key was generated.
DSA(DSS) key was generated.
SSH Public Key Authentication is disabled.

There don’t seem to be any in-depth settings related to the ssh server here that I can modify.

—

Second issue —

I have another two Cisco 2900 Series routers at a different site on firmware v15.4(3)M3 trying to ssh into a Dell N1548P stack on firmware v6.3.0.6. All attempts fail with —

router#ssh 5.6.7.8
Password:
[Connection to 5.6.7.8 aborted: error status 0]

Buffer log shows —

SSH2 CLIENT 0:  Channel open failed, reason = 1752134516

SSH config on router —

SSH Enabled - version 2.0
Authentication methods:publickey,keyboard-interactive,password
Encryption Algorithms:aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
MAC Algorithms:hmac-sha1,hmac-sha1-96
Authentication timeout: 120 secs; Authentication retries: 3
Minimum expected Diffie Hellman key size : 1024 bits
IOS Keys in SECSH format(ssh-rsa, base64 encoded):
ssh-rsa keystringgoeshere

SSH config on N1548P stack —

SSH Server enabled.  Port: 22
Protocol Levels: Versions 1 and 2.
SSH Connections Currently in Use: ............. 1
Maximum number of SSH Sessions Allowed: ....... 5
SSH Session Timeout: .......................... 600
RSA key was generated.
DSA key was generated.
SSH Public Key Authentication is disabled.

In this particular scenario, if I modify the router to use SSH v1, it’s able to connect. Using v2, it’s not. Of course, we don’t want to use v1. I haven’t been able to figure out what reason «1752134516» means.

—

Note that I’m able to SSH into both switch stacks directly. It’s only the routers that aren’t able to connect.

Thanks for any help.

>[оверквотинг удален]
>>>
>>>Как входим, и как ругается ?
>>
>>
>>Main#ssh -l root 172.19.2.62
>>
>>[Connection to 172.19.2.62 aborted: error status 0]
>
>Мне помогало понижение версии протокола 2->1:
>Main#ssh -v 1 -l root 172.19.2.62

Гы. у вас разрешен удаленный доступ root-у ? — тада мы идем к вам!!

Проверить, что в конфиге ссх нет запрета на вход рута.

Источник

Устранение неполадок подключения по SSH в Linux

Неполадки, связанные с работой SSH совсем не редкость и возникают как по причине неправильных действий пользователей, таки из-за неправильно заданной конфигурации самой системы SSH. Но в любом случае, для устранения всевозможных неполадок, нужно уметь применять определённые методы, помогающие найти и исправить неполадку. В этой статье будут рассмотрены различные ситуации, в которых могут возникнуть ошибки c подключением по SSH, а также методы их устранения.

Неправильное имя хоста

При выполнении команды подключения по SSH на стороне клиента может быть получена ошибка:

Это значит, что имя хоста «hostname.com» не может быть сопоставлено с IP-адресом сервера SSH. Зачастую, это связано с работой DNS. В первую очередь, следует убедиться в правильности написания самого имени хоста. Также можно проверить разрешение этого хоста с помощью команды ping или сторонних сервисов. Если же во всех случаях наблюдается та же ошибка, можно попытаться подключиться, используя непосредственно IP-адрес:

Ошибка с истечением времени соединения

Такая ошибка происходит, когда сервер SSH не может ответить подключающемуся к нему клиенту в течение определённого промежутка времени:

Для исправления этой ошибки необходимо в первую очередь сделать следующее:

• проверить правильность имени и/или IP-адреса хоста сервера SSH;
• проверить, что указанный порт (22) доступен для подключения. В некоторых сетях он может быть заблокирован;
• проверить режим политики брандмауэра, политика которого по-умолчанию должна быть не DROP.

Отклонение соединения

Данная ошибка схожа с ошибкой истечения времени соединения и выглядит следующим образом:

Методы её устранения такие же, как и в случае, описанном в предыдущей главе, но дополнительно нужно проверить, что для подключения используется именно тот порт, который настроен на стороне сервера. Иногда, в целях безопасности его задают отличным от стандартного 22.

Настройка брандмауэра

Как известно, брандмауэры могут блокировать определённые порты и/или сетевые сервисы. Брандмауэров существует множество и в разных дистрибутивах Linux используются разные брандмауэры. Так, для Ubuntu это UFW, а для CentOS – FirewallD. Также можно использовать стандартный сервис iptables.

В зависимости от того, какой порт используется для подключения по SSH, необходимо настроить соответствующее подключение для обслуживания брандмауэром. Для начала нужно узнать, какие правила используются в данный момент. Для iptables это позволяет сделать команда:

Если политика iptables по-умолчанию DROP (или REJECT), то необходимо для правил цепочки INPUT задать разрешение для порта, используемого для SSH.
Для брандмауэра FirewallD получить список используемых правил позволяет команда:

Для работы SSH в выводе должно быть правило «dhcpv6-client http ssh». Также необходимо проверить и порт, заданный для SSH. Для этого вместо опции «—list-services» нужно использовать «—list-ports».
Для брандмауэра UFW нужно выполнить:

Как видно, в списке должен присутствовать порт SSH, в данном случае 22. Он может быть и другим, в зависимости от того, что задано в настройках сервера SSH.

Проверка состояния сервера SSH

При получении ошибок подключения также не лишним будет проверить, запущен ли сам сервер SSH. Это можно сделать при помощи команды systemctl:

В случае, если демон SSH не работает, то в строке Active будет следующее:

Для запуска демона следует использовать команду:

Следует также обратить внимание на то, что обычно в дистрибутивах CentOS демон SSH называется sshd, а в Ubuntu – ssh.

Проверка порта для работы SSH

Чтобы проверить, какой порт настроен для использования сервером SSH, можно просмотреть соответствующий параметр в конфигурационном файле /etc/ssh/ssh_config . Для этого можно использовать команду grep для поиска по файлу:

Как видно из данного вывода, сервер SSH настроен на работу по стандартному порту 22. Параметр Port можно переопределять, но тогда необходимо внести изменения в соответствующие правила для брандмауэров, а также проинформировать клиентов о том, какой порт используется для подключения по SSH вместо стандартного.

Заключение

В заключение следует заметить, что в данной статье были рассмотрены лишь самые общие и распространённые неполадки, связанные с подключением по SSH. Обычно это легко выявляемые и быстро устраняемые ошибки.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник

Adblock
detector

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

Первая проблема —

У меня есть два маршрутизатора Cisco 2900 Series на прошивке v15.2(4)M4, которые пытаются войти в стек Dell 5548P на прошивке v4.1.0.8. Все попытки мгновенно терпят неудачу с —

Журнал буфера показывает —

Если я попытаюсь изменить длину ключа DH на маршрутизаторе, попытки все равно не увенчаются успехом, а журнал буфера покажет — {{{{784784}}}}.

Конфигурация SSH на маршрутизаторе —

Конфигурация SSH на стеке 5548P — {{5887878}}

Похоже, что здесь нет никаких глубоких настроек, связанных с ssh-сервером, которые я мог бы изменить.

—

Вторая проблема —

У меня есть еще два маршрутизатора Cisco 2900 Series на другом сайте на прошивке v15.4(3)M3, которые пытаются войти в стек Dell N1548P на прошивке v6.3.0.6. Все попытки заканчиваются неудачей с —

Журнал буфера показывает —

Конфигурация SSH на маршрутизаторе —

Конфигурация SSH на стеке N1548P — {{{777}}}

В данном конкретном сценарии, если я модифицирую маршрутизатор для использования SSH v1, он сможет подключиться. При использовании v2 — нет. Конечно, мы не хотим использовать v1. Я не смог понять, что означает причина «1752134516».

—

Обратите внимание, что я могу напрямую подключиться по SSH к обоим стекам коммутаторов. Только маршрутизаторы не могут подключиться.

Спасибо за любую помощь.

Hello All,

My ISP needs connect with switches extreme by SSH from rouert cisco since we want to maintain this connection as contingency.

These are logs the cisco router

RTT_BF_HC_ENVIGADO_PPAL#ssh 1.1.1.1

[Connection to 10.128.35.4 aborted: error status 0]
RTT_BF_HC_ENVIGADO_PPAL#
Sep 8 16:10:50.648: SSH CLIENT0: protocol version id is — SSH-2.0-4.1.2 SSH Secure Shell Toolkit
Sep 8 16:10:50.648: SSH CLIENT0: sent protocol version id SSH-2.0-Cisco-1.25
Sep 8 16:10:50.648: SSH2 CLIENT 0: send:packet of length 344 (length also includes padlen of 5)
Sep 8 16:10:50.648: SSH2 CLIENT 0: SSH2_MSG_KEXINIT sent
Sep 8 16:10:50.652: SSH2 CLIENT 0: ssh_receive: 424 bytes received
Sep 8 16:10:50.652: SSH2 CLIENT 0: input: total packet length of 424 bytes
Sep 8 16:10:50.652: SSH2 CLIENT 0: partial packet length(block size)8 bytes,needed 416 bytes,
maclen 0
Sep 8 16:10:50.652: SSH2 CLIENT 0: input: padlength 8 bytes
Sep 8 16:10:50.652: SSH2 CLIENT 0: SSH2_MSG_KEXINIT received
Sep 8 16:10:50.652: SSH2:kex: server->client enc:aes128-cbc mac:hmac-sha1
Sep 8 16:10:50.652: SSH2:kex: client->server enc:aes128-cbc mac:hmac-sha1
Sep 8 16:10:50.652: SSH2 CLIENT 0: hostkey algo not supported: client ssh-rsa, server ssh-dss
Sep 8 16:10:50.652: SSH CLIENT0: Session disconnected — error 0x00

RTT_BF_HC_ENVIGADO_PPAL#ssh 1.1.1.1

[Connection to 10.128.35.4 aborted: error status 0]
RTT_BF_HC_ENVIGADO_PPAL#ssh 1.1.1.1
Sep 8 15:54:52.497: SSH2 CLIENT 0: hostkey algo not supported: client ssh-rsa, ho log