Соединение отклонено — не могу подключиться по SSH к Unifi AP.

Соединение отклонено — не могу подключиться по SSH к Unifi AP., UniFi Network

howlincolin00

Guest

16.04.2014 11:11:00

У нас есть Unifi AP в удалённом месте, подключенный к Nanostation в режиме роутера, который, в свою очередь, беспроводно подключен к нашей сети. Кто-то (то есть я) сбросил Unifi AP к заводским настройкам. С тех пор мы не можем подключиться к AP по SSH, чтобы установить inform URL. Если мы пытаемся подключиться по SSH, получаем: XM.v5.5.6# ssh ubnt@192.168.1.39 ssh: exited: Error connecting: Connection refused. AP получает IP по DHCP от Nanostation, 192.168.1.39. Мы можем пинговать этот IP с Nanostation, но, как выше, не можем подключиться по SSH.

Есть какие-нибудь идеи? Если до этого дойдёт, мы поедем на место, но есть ли способ получить доступ к нему удалённо?

Сообщите, если нужна какая-то дополнительная информация.

cusco

Guest

21.04.2017 09:58:00

Привет!

У нас иногда проваливаются обновления прошивки на AP, и они показывают как отключенные, но при этом пингуются и принимают SSH-соединение. При попытке авторизоваться с правильными учетными данными вылетает ошибка с некорректным именем пользователя/паролем. Я получаю следующее:

Can you help me on what to do?
medic@10.200.222.236’s password:

debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
Authenticated to 10.200.222.236 ([10.200.222.236]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: packet_set_tos: set IP_TOS 0x08
debug2: client_session2_setup: id 0
debug1: Sending environment.
debug3: Ignored env TERM
debug3: Ignored env SHELL
debug3: Ignored env SSH_CLIENT
debug3: Ignored env SSH_TTY
debug3: Ignored env USER
debug3: Ignored env LS_COLORS
debug3: Ignored env MAIL
debug3: Ignored env PATH
debug3: Ignored env PWD
debug1: Sending env LANG = en_GB.UTF-8
debug2: channel 0: request env confirm 0
debug3: Ignored env SHLVL
debug3: Ignored env HOME
debug3: Ignored env LANGUAGE
debug3: Ignored env LOGNAME
debug3: Ignored env SSH_CONNECTION
debug3: Ignored env _
debug1: Sending command: reboot
debug2: channel 0: request exec confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 24576 rmax 32759
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug2: channel 0: rcvd close
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1)

Transferred: sent 2448, received 880 bytes, in 0.6 seconds
Bytes per second: sent 4125.6, received 1483.1
debug1: Exit status 1

consatunifi Guest	#3 16.02.2017 14:14:00 Привет, у меня точно такая же проблема. Какие-нибудь обновления? Пробовал всё, включая TFTP-recovery. Всё равно нет доступа к порту 22.

ub40

Guest

09.12.2016 10:31:00

Обновление: Час назад 2 из 4 точек доступа сами собой решили перейти на старый контроллер (который все еще работает, точки доступа не забыли). Пока были на старом контроллере, их SSH-порт вдруг стал доступен. Теперь их забыли на старом контроллере, они автоматически вернулись на новый контроллер, и опять: SSH-порт не открыт (перепровизионирование не помогло, параметры аутентификации устройства установлены). ?

ub40

Guest

08.12.2016 14:45:00

@danmero

: Ты ответил на пост, которому 2 года. :-)

Обновление: ACv1 был сброшен (нажатием кнопки +5 секунд), и успешно обновлён до 3.7.29 через контроллер. UAP-ы тоже обновились до 3.7.29 и приняли свои настройки, кнопку сброса использовать не пришлось. Порт SSH всё ещё не отображается, в сканировании видны только 53 и 80. Nagios пробивает регулярно, и старый контроллер тоже онлайн – может быть, это заставляет AP-ы переходить в какой-то защитный режим в отношении SSH?

danmero Guest	#6 08.12.2016 03:58:00 Ты проверял альтернативные порты? Твоя проблема выглядит похоже, но на самом деле отличается, тебе стоит создать свою тему. С уважением,

danmero Guest	#7 08.12.2016 03:56:00 Какая у вас основная ОС? Попробовали: ssh -vvvvvС уважением,

ub40

Guest

08.12.2016 02:15:00

Обновление: "Забыл" про один UAP, потом успешно его переопределил. Контроллер выглядит нормально, вроде работает, но: я не могу изменить НИКАКИЕ настройки, не могу переместить его от режима Auto = High power, он просто не провизионится. И все еще нет доступа по SSH.

@UBNT-Brandon

ub40 Guest	#9 07.12.2016 14:11:00 Все (!) мои точки доступа перестали отвечать на 22-м порту, nmap это подтверждает. Перезагрузка питания не помогла, сброс ещё не производился, потому что это удалённая площадка . Это произошло во время миграции точек доступа с одного контроллера (CloudKey 5.3.8, стабильный кандидат) на Linux-контроллер в той же сети. Linux-контроллер 4.8.18 (вроде бы) «знал» эти точки доступа ещё со времён CloudKey, они не были забыты. Я успешно перенёс 3 из них (все простые UAP v1) на Linux-контроллер через SSH, настроил inform (только один раз). Эти точки доступа работают отлично и выполняют свою работу. Четвёртая точка доступа (ACv1) на мгновение успешно подключилась через веб-интерфейс на Linux-контроллере, но затем быстро пропала, она больше не показывается как доступная для подключения ни на одном из двух контроллеров —> подключение не удалось, новый контроллер всё ещё показывает для неё корректное время работы, старый — нет. На втором этапе я также обновил Linux-контроллер до 5.3.8 и восстановил настройки из бэкапа CloudKey. Без изменений. Прошивка точек доступа — 3.7.28. У контроллеров были и есть разные IP-адреса, но они правильно указывались через DNS и DHCP option.

Читают тему (гостей: 1)