На контроллере Wiren Board (WB7, релиз wb-2507) утром произошло массовое обновление системы — было выполнено apt upgrade, обновилось около 200 пакетов. В процессе обновление прервалось, после чего часть сервисов оказалась недонастроенной (dpkg was interrupted), и их пришлось вручную довести через dpkg --configure -a.
По журналу видно следующее:
в 10:32 был вход под root с адреса 127.0.0.1
тип сессии: ssh root@notty
через пару минут после этого началось выполнение apt upgrade
Это выглядит как локальный запуск команды через SSH без терминала (notty), то есть команду, вероятно, инициировало какое-то приложение или сервис на самом контроллере, а не человек, подключившийся по SSH извне.
При этом:
unattended-upgrades не настроен
apt-daily-upgrade по таймерам systemd в это время не запускался
прямого внешнего SSH-подключения не было
Подскажите, пожалуйста:
Какие компоненты Wiren Board могут инициировать apt upgrade автоматически?
(например: wb-update-manager, wb-cloud-agent, web-интерфейс, какие-то сервисы обновления и т.п.)
Может ли облачный агент WB или какой-то внутренний сервис запускать обновление системы?
Есть ли в системе стандартный механизм автообновления, который мог бы привести к такому поведению?
Хотелось бы понять источник запуска обновления и правильно настроить механизм обновлений на контроллере.
Добрый день.
Вошел в ssh из облачного сервиса, для проверки.
Вижу:
Mar 16 13:01:19 wirenboard-AQASN7R6 sshd[24491]: Accepted password for root from 127.0.0.1 port 40800 ssh2
Mar 16 13:01:19 wirenboard-AQASN7R6 sshd[24491]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0)
Mar 16 13:01:19 wirenboard-AQASN7R6 systemd-logind[327]: New session 150 of user root.
Mar 16 13:01:19 wirenboard-AQASN7R6 systemd[1]: Started Session 150 of user root.
Из какого лога?
Автоматического выполнения upgrade - нет, нигде.
Если использовать ssh через облако - можно. Но не автоматически.
-1.По поводу из какого лога: journalctl --since “2026-03-16 10:30:00” --until “2026-03-16 10:40:00” | grep sshd
Mar 16 10:32:03 wirenboard-A2RC46TV sshd[20067]: Accepted password for root from 127.0.0.1 port 54802 ssh2
Mar 16 10:32:03 wirenboard-A2RC46TV sshd[20067]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0)
Mar 16 10:38:43 wirenboard-A2RC46TV watchdog[29114]: pidfile: /var/run/sshd.pid
и далее journalctl _PID=20067
MESSAGE=pam_unix(sshd:session): session closed for user root
_CMDLINE=sshd: root@notty
_SYSTEMD_CGROUP=/user.slice/user-0.slice/session-c2.scope
_SYSTEMD_SESSION=c2
_SYSTEMD_UNIT=session-c2.scope
_SYSTEMD_INVOCATION_ID=bace289d81834e73b9a4c7ee8c489297
_SOURCE_REALTIME_TIMESTAMP=1773647476907532
2. Есть ли возможность приватно отправить диагностическую информацию? Часть данных из журналов может содержать чувствительную информацию, поэтому удобнее было бы передать их не в публичной теме.
1. По поводу вывода, что вход был выполнен через облачный SSH.
В журнале на контроллере я вижу только следующее:
Accepted password for root from 127.0.0.1
_CMDLINE=sshd: root@notty
Это действительно выглядит как SSH-сессия без TTY, но из этих строк не очевидно, что соединение пришло именно через облачный сервис — теоретически это мог инициировать и любой локальный процесс или скрипт на самом контроллере.
Подскажите, пожалуйста, на основании каких признаков вы сделали вывод, что вход был именно через cloud-SSH?
Есть ли в системе логи или метки, по которым можно однозначно определить, что соединение пришло через wb-cloud-agent / frpc, а не было инициировано локальным процессом?
2. По поводу облачного аккаунта.
Сейчас контроллер показывает, что он подключён к облаку (Connected to cloud), но у меня утерян доступ к учётной записи, к которой он привязан.
Есть ли инструкция:
как на контроллере узнать, к какому аккаунту (e-mail) он привязан,
как восстановить доступ к этой учётной записи,
или как полностью сбросить привязку контроллера к облаку и привязать его к новому аккаунту?
Полностью (на мой взгляд) совпадают признаки. Поскольку на контроллере нет больше сервисов или скриптов которые могут запускать сеансы. По крайней мере в заводском ПО. Не исключаю, конечно, что было что-то дополнительное установлено.
Так, понятно.
Судя по состоянию - да, контроллер подключен к облаку, к действующей учетной записи.
А кто занимался настройкой и пусконаладкой? Если это какой-то интегратор - то целесообразно у него спросить. Ну и отвязать (или передать в другой аккаунт, в облаке уже есть такая функция) они смогут сами.