Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
"Меняющиеся как песок" учётные данные UniFi?, UniFi Network
 
Я фрилансер в сфере IT (ИП) с опытом более 20 лет. В последние несколько лет я практически исключительно устанавливаю оборудование UniFi. За это время я настроил около 12 разных контроллеров UniFi (для 12 разных клиентов), все на устройствах Cloud Key. Могу сказать, что в целом я доволен продуктами UniFi. Однако проблема, которая возникала на примерно *пяти* из этих объектов, недавно вызвала большую проблему на шестом:

Когда я настраиваю что-либо (включая оборудование UniFi), я очень тщательно записываю созданные имена пользователей и пароли. Действительно, наборы учетных данных, которые нужно создавать на устройствах UniFi, довольно многочисленны (и, честно говоря, запутанны). Например, за последние годы (и версии прошивки) для UniFi я создавал несколько паролей и/или учетных записей, таких как: «SSH password», «Device Password (учетные данные)», учетные данные контроллера, учетные данные Cloud Key и так далее. Хотя я все это документирую, можно сказать, что меня часто сбивает с толку количество необходимых паролей при запуске нового UniFi проекта. При этом я бы сказал, что в любом случае один из наборов учетных данных изначально работает для доступа к контроллеру UniFi, и я записываю именно его (при этом остальные тоже держу в документации на всякий случай).

Потом, спустя несколько месяцев или лет, пока я обновляю прошивку, на примерно 5 моих объектах пароли, которые *раньше* работали для доступа к контроллеру, перестают работать! К счастью, в отчаянии я пробую другие учетные данные UniFi, которые изначально записывал, – и они начинают работать, так что я обновляю документацию, и проблема решается.

Однако, пройдя через это несколько раз, я решил быть умнее на одном из новых объектов UniFi и использовать один и тот же пароль для всех перечисленных выше учетных данных. Я думал, что тогда, когда что-то снова поменяется (из-за обновлений прошивки, как я предполагаю), это не будет проблемой, ведь пароль останется одним и тем же. Но для этого шестого объекта означало, что у меня в документации был всего один пароль.

Прошло время, и эта «движущаяся бездна» учетных данных UniFi ударила по этому шестому объекту, и теперь я полностью заблокирован там! Я пробовал все варианты стандартных паролей, ничего не работает, и, похоже, мне придется делать полный сброс к заводским настройкам!

Моя вина ли это? Конечно, да. Но то, почему я так не думаю, — это потому, что это означало бы, что я был небрежен с документацией паролей примерно в 50% моих объектов UniFi, а значит, скорее всего, и с документацией по паролям в 50% всех IT-продуктов и сервисов для всех моих клиентов за последние 20 лет. Это абсолютно не соответствует действительности...

За все это время у меня редко возникала проблема с «забытыми паролями». При этом количество таких проблем со стеком UniFi намного выше, чем с любыми другими продуктами. Это заставляет меня задуматься — не моя ли это ошибка?

Проблема похожа (а в некоторых случаях, возможно, идентична) следующему утверждению: «ПРИМЕЧАНИЕ: в прошивках до версии 3 (когда появилась функция multi-sites) имя пользователя и пароль (после привязки) соответствовали имени администратора и паролю, настроенным в контроллере UniFi» с этого сайта: https://help.ubnt.com/hc/en-us/articles/204909374-UniFi-Default-Username-and-Password

Кто-нибудь еще сталкивался с этой проблемой «движущихся песков» учетных данных UniFi (вероятно, связанной с обновлениями прошивки), или это сугубо моя беда, и значит, я сам виноват? Заранее спасибо за любые мысли по этому поводу!
 
О, понимаю тебя насчёт запутанных инструкций — в основном, как по мне, из-за старой документации и всяких «мастеров настройки». Там реально продаётся древнее оборудование с древней прошивкой, и это совсем не улучшает ситуацию. Вывод такая: «не запускай эти мастера настройки, лучше сожги их в огне» 😀
 
Согласен с тобой, моя прежняя путаница с «какой логин за что отвечает» точно сыграла роль в этих моих проблемах. Но как тогда *никто* другой *не запутался* так же, если в этой статье из UniFi KB (о том, как впервые настроить Cloud Key): https://help.ubnt.com/hc/en-us/articles/219051528-UniFi-How-to-Set-Up-your-Cloud-Key-and-UAP-for-beginners- показано создание *одного* набора учётных данных?… Вот скриншот... видишь, как там даже *предлагается* и даётся возможность создать только *один* набор логина и пароля? («используйте одно и то же имя и пароль для SSH-доступа»). https://help.ubnt.com/hc/article_attachments/115019126928/Screen_Shot_2017-08-08_at_1.33.29_PM.png Откуда мне было знать, что создание этого одного набора учёток автоматически породит *три* (или больше) наборов данных? (как мы выяснили: учётки Cloud Key, контроллера и SSH... ты ещё предлагаешь *четвёртый* набор, «учётные записи аккаунтов», что бы это ни значило). Почему *никто* больше не проверил (или даже не снял, если там стоял по умолчанию) этот чекбокс «использовать тот же пароль для SSH», который потом бы показал предупреждение о дублировании пароля SSH при установке того обновления контроллера, которое я упоминал? Как тебе удалось избежать такой путаницы, Vestas? Как вообще все остальные, кто настраивает Cloud Keys, обходят эту проблему, кроме меня? Ответы на эти вопросы, возможно, помогут мне не повторять такую же ошибку в будущем!

И наконец, даже несмотря на мою серьёзную путаницу с «каким логином к чему», главный момент в том, что на протяжении месяцев или даже лет *до этого* (в зависимости от версии контроллера) всё *работало*... Меня никогда не выкидывало из UniFi контроллера, все мои задокументированные учётки всегда работали и были правильными. Можно сказать, что это даже не была путаница, ведь всё работало, *пока* не вышло то обновление контроллера, которое я по чуть-чуть стал ставить на свои контроллеры. Да, в этом обновлении явно произошёл «разбор полётов» с моими знаниями о логинах UniFi, что-то изменилось в этой версии... с этим всё понятно.

Спасибо за твои посты, Vestas, я их ценю и согласен — моя путаница была хотя бы частью этих проблем.
 
99% уверен, что проблема именно в вас — похоже, вы запутались между входами в UC-CK, контроллеры, аккаунты и SSH-устройства. Примерно год назад действительно была такая проблема, как я уже говорил раньше в переписке, но явно это не ваш случай. Извините, но, думаю, что проблема, скорее всего, в вас 😀
 
РЕЗУЛЬТАТЫ ПЯТОГО ОБНОВЛЕНИЯ КОНТРОЛЛЕРА: Похоже, что никаких учётных данных не изменилось ни до, ни после обновления контроллера (меня не просили менять пароль для SSH). Скорее всего, это потому, что учётные данные контроллера изначально отличались от SSH-учётных данных.
 
РЕЗУЛЬТАТЫ ЧЕТВЁРТОГО ОБНОВЛЕНИЯ КОНТРОЛЛЕРА: До обновления *имена пользователей* были одинаковыми (для Cloud Key, контроллера и SSH-входов). Пароли для контроллера и SSH совпадали, но пароль для прошивки Cloud Key был другим. После обновления все учётные данные остались прежними, кроме пароля SSH — он стал рекомендованным (из того же похожего скриншота).
 
РЕЗУЛЬТАТЫ ЧЕТВЁРТОГО ОБНОВЛЕНИЯ КОНТРОЛЛЕРА: Перед обновлением я обнаружил, что учётные данные контроллера (логин X и пароль Y) и данные для SSH-аутентификации устройства совпадают, но учётные данные Cloud Key отличаются. После обновления контроллера учётные данные Cloud Key и контроллера остались прежними, а пароль SSH (только он) поменялся на тот, который был предложен (по аналогичному скриншоту). Это (вместе с другими внимательно отслеженными обновлениями контроллера), похоже, говорит о том, что после обновления до определённой версии контроллера при первой авторизации, если обнаруживается, что пароль SSH и пароль контроллера совпадают, появляется скриншот с предложением сменить пароль SSH (и даже предлагается использовать длинный случайный пароль). К слову, я всегда принимаю и меняю пароль SSH на предложенный новый пароль.
 
РЕЗУЛЬТАТЫ ОБНОВЛЕНИЯ ТРЕТЬЕГО КОНТРОЛЛЕРА: До обновления я обнаружил, что имя пользователя (x) и пароль (y) совпадали для всего — входа в Cloud Key, входа в контроллер и SSH-аутентификации устройств. После обновления контроллера учётные данные для Cloud Key остались прежними, данные для контроллера тоже не изменились, но пароль для SSH-аутентификации устройств изменился (на тот, который был показан на похожем скриншоте выше после обновления контроллера... имя пользователя осталось тем же).
 
Brontide, я забыл спросить: ты хочешь сказать, что никогда не видел скриншот, который я публиковал раньше в этой теме? Кстати, кто-нибудь вообще его видел, или я тут один такой, хотя сам сталкиваюсь с этим почти при каждом обновлении UniFi контроллера в последнее время? Спасибо!
 
Больше документации и исследований по этой проблеме (хотя бы для себя, если для других нет): версия контроллера *до* появления этой проблемы — 5.6.29 (хотя, возможно, есть ещё несколько более новых версий контроллера до того, как проблема появилась... я просто проверил, что этой проблемы не было в версии 5.6.29 и ранее).
 
Спасибо за ваши идеи и пост... Я с радостью приму любые предложения по этому поводу! Большинство паролей от моих контроллеров (если не все) содержат специальные символы. По крайней мере, я точно видел в них восклицательные знаки, знаки процента и символ над цифрой 6 (это, кажется, называется «карет»?). Вряд ли у кого-то есть SSH-ключи или пароли от этих контроллеров (я тут один отвечаю за всё), но, к сожалению, нельзя быть на 100% уверенным, что сервис менеджера паролей или аккаунт не взломали. Несколько месяцев назад я на собственном опыте понял, что Cloud Keys (и PoE-коммутаторы, к которым они подключены) обязательно должны быть подключены к ИБП, поэтому сейчас постепенно ставлю все эти устройства на ИБП. Думаю, что сейчас я примерно на 30-40% выполнил эту задачу. Есть ещё мысли по этому поводу? Ещё раз спасибо за ваш пост!
 
Головоломка, потому что я никогда с таким не сталкивался. Есть ли в вашем пароле какие-то специальные символы, например обратные слэши, восклицательные знаки, пробелы, неаски-символы или знаки процента? Есть ли вероятность, что кто-то владеет вашим ssh-ключом или паролями от этих сайтов? Подключены ли cloudkeys (или PoE-коммутатор) к ИБП?
 
РЕЗУЛЬТАТЫ ВТОРОГО ОБНОВЛЕНИЯ КОНТРОЛЛЕРА: здесь данные для входа в устройство Cloud key и контроллер остались прежними после обновления контроллера. Видимо, потому что у этих учеток изначально были разные *имена пользователей*? Интересно, что с этим контроллером я, как обычно, принял предложенный новый SSH-пароль (по почти такому же скриншоту, как выше), но здесь SSH-пароль оказался совсем *другим* вторым новым паролем! Если бы я не проверил это прямо в контроллере, я бы так и не узнал (и не задокументировал), а рано или поздно просто бы заблокировался, так или иначе. Если этот сбой случился один раз (как сейчас), интересно, сколько ещё раз это могло происходить с моими предыдущими обновленными контроллерами и сколько таких сбоев было причиной моих блокировок на прошлых контроллерах?!?!!
 
Я выяснил, что у меня всё ещё есть 6 разных контроллеров UniFi на версии контроллера 5.6.29. Поэтому я буду использовать каждый из этих шести оставшихся контроллеров как тестовые образцы и буду *крайне* осторожен, чтобы задокументировать, какие были данные для входа до обновления (то есть на версии 5.6.29), а затем точно зафиксирую, что произошло после обновления каждого контроллера до последней доступной версии. Свои выводы по большинству (если не по всем) из этих шести обновлений контроллеров UniFi я опубликую здесь, опять же только для дополнительной документации и исследования этой проблемы (по крайней мере для себя, если не для кого-то ещё).

Вот что произошло при обновлении первого контроллера UniFi (с версии 5.6.29): кажется, что данные для входа в Cloud Key стали *такими же*, как и данные для входа в контроллер (а данные контроллера *раньше* совпадали с предыдущими SSH / Device Authentication данными). *Новый* пароль для SSH / Device Authentication (только он) стал тем, что было предложено (в этом случае) на том же скриншоте, который я раньше сюда выкладывал.
 
Больше документации и исследований по этой проблеме (по крайней мере для меня, если не для кого-то ещё): теперь я уверен, что эта проблема *появилась* в версии контроллера 5.6.30, ведь именно она стоит на первом моём UniFi-контроллере с этой проблемой, а раньше я уже выяснял, что версия UniFi контроллера 5.6.29 такой проблемы *не* имела и не вызывала.
 
Сразу после моего последнего сообщения в этой теме я стал видеть всплывающие окна при входе в несколько разных моих контроллеров UniFi:  
 

Я знаю, что по крайней мере *некоторые* из контроллеров UniFi, где появлялось это окно, были теми же контроллерами, из которых меня блокировало (и возможно, так было 100% времени).  
Это всплывающее окно появляется у меня именно *после* обновления версий контроллера.  

Я считаю, что это *связано* с той проблемой, по которой я начал эту тему, и поэтому считаю это доказательством того, что я не придумываю себе, но пока этого всё ещё недостаточно, чтобы «собрать все кусочки пазла».  

Кто-нибудь может объяснить причины моих проблем (когда я блокируюсь из-за того, что пароли на нескольких контроллерах UniFi меняются сами по себе)?  
Спасибо!
Страницы: 1
Читают тему (гостей: 1)