Удаленный Raspberry Pi 4 отвечает на ping, и порт SSH открыт, но SSH зависает после попытки выполнить “perl cpan install” с этой командой “perl -MCPAN -e’shell'”.

Вопрос или проблема

Я пытался установить CPAN на полностью обновлённый удалённый (другая страна) Raspberry Pi 4, используя эту команду

perl -MCPAN -e'shell'

Доступ осуществлялся через графическое соединение Raspberry Pi Connect, и я выбрал автоматическую установку, после чего установка началась.

Через некоторое время экран завис, и соединение оборвалось. Я попытался переподключиться, но попытка просто закончилась тайм-аутом.

Я также настроил простое соединение Raspberry Pi Connect, tailscale и Remote. Методы соединения SSH к этому Raspberry Pi также заканчиваются тайм-аутом.

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

pi@Pi-Hole-3:~ $ ssh -vvv [email protected]
OpenSSH_9.2p1 Debian-2+deb12u4, OpenSSL 3.0.15 3 Sep 2024
debug1: Reading configuration data /home/pi/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolve_canonicalize: hostname 192.168.1.97 is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/pi/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/pi/.ssh/known_hosts2'
debug3: ssh_connect_direct: entering
debug1: Connecting to 192.168.1.97 [192.168.1.97] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x10
debug1: Connection established.
debug1: identity file /home/pi/.ssh/id_rsa type -1
debug1: identity file /home/pi/.ssh/id_rsa-cert type -1
debug1: identity file /home/pi/.ssh/id_ecdsa type -1
debug1: identity file /home/pi/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/pi/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/pi/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/pi/.ssh/id_ed25519 type -1
debug1: identity file /home/pi/.ssh/id_ed25519-cert type -1
debug1: identity file /home/pi/.ssh/id_ed25519_sk type -1
debug1: identity file /home/pi/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/pi/.ssh/id_xmss type -1
debug1: identity file /home/pi/.ssh/id_xmss-cert type -1
debug1: identity file /home/pi/.ssh/id_dsa type -1
debug1: identity file /home/pi/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u4
^C
pi@Pi-Hole-3:~ $ nmap -p 1-1023 192.168.1.97
Starting Nmap 7.93 ( https://nmap.org ) at 2025-01-24 15:37 GMT
Nmap scan report for 192.168.1.97
Host is up (0.00075s latency).
Not shown: 1022 closed tcp ports (conn-refused)
PORT   STATE SERVICE
22/tcp open  ssh

Nmap done: 1 IP address (1 host up) scanned in 0.30 seconds
pi@Pi-Hole-3

Я обнаружил, что у Raspberry Pi есть аппаратный сторожевой таймер, но даже если я проверю отсутствие активности на eth0, могла ли эта ситуация вызвать его перезагрузку?

Что же сделал perl cpan, чтобы сломать SSH?

Есть ли способ получить доступ или принудить перезагрузку, не подходя физически к удалённому Raspberry Pi?

Ответ или решение

Теория

Ваше описание проблемы указывает на несколько возможных причин возникшей ситуации с Raspberry Pi 4. Сначала рассмотрим, что могло произойти, когда вы пытались установить CPAN с помощью команды perl -MCPAN -e 'shell'. Данный процесс идет через пакетный менеджер Perl и имеет ряд зависимостей, что может влиять на работу системы. Если система зависает во время процесса установки, это может быть связано со следующими аспектами:

  1. Проблемы с ресурсами системы: Установка CPAN с задействованием различных модулей может быть требованиям по процессорному времени и оперативной памяти. На Raspberry Pi 4, несмотря на ее приличные характеристики, могут возникать сложности с управлением ресурсами в условиях высокой нагрузки.

  2. Прерывание сетевого подключения: Разрыв визуального соединения и невозможность повторного подключения указывают на проблемы в сети или с прошивкой устройства, таких как недостаточное питание, перегрев или сбой в сетевых настройках.

  3. Конфигурация SSH: Если возникает проблема с зависанием при попытке SSH-соединения, может быть, что SSH работает некорректно из-за исчерпания системных ресурсов, конфликта зависимостей или неправильной конфигурации.

  4. Аппаратные сбои: Ваше упоминание об аппаратном стороже указывает на возможность его некорректной работы, что могло быть спровоцировано отсутствием сетевой активности. Это немаловажный фактор, так как системы мониторинга иногда воспринимают такие состояния как рутину и перезапускают устройство для восстановления работоспособности.

Пример

На практике, прежде всего, рекомендуется следующее:

  • Определите статусы ресурсов: Проанализируйте выводы системных журналов для обнаружения потенциальных проблем на уровне ОС.

  • Средства анализа сети: Используйте трассировку сети и дополнительные диагностические утилиты, чтобы убедиться в отсутствии сетевых конфликтов.

  • Регулярные перезагрузки и обновления прошивки: Помогают предотвратить подобные сбои. Контролируйте температуру устройства и обеспечьте его надлежащее охлаждение.

Применение

  1. Проверка логов: Получите доступ к локальному узлу в той же сети, попробуйте просмотреть журналы (/var/log/syslog или файлы журналов SSH) на устройстве Raspberry Pi. Это может дать подсказки о том, что пошло не так в последний успешный момент работы системы.

  2. Используйте альтернативные методы подключения: Попробуйте заново подключиться через Tailscale или другой ранее настроенный VPN, что может помочь обойти текущие сетевые проблемы.

  3. Удаленный доступ через соседний узел: Если доступ к Raspberry Pi невозможен, и оно остается в локальной сети, попробуйте использовать другой локальный узел как промежуточное соединение.

  4. Запуск сторожа: Если возможно выполнить в систему команду сторожа, выполните безопасное завершение всех процессов, чтобы избежать повторения ситуации. Рассмотрите настроить пороговые показатели для сторожа, избегая ложных срабатываний в будущем.

  5. Физический перезапуск: В случае, если никакие программные меры не приводят к успеху, и если доступ физически возможен, необходим ручной перезапуск Raspberry Pi.

  6. Планирование дальнейших действий: Постарайтесь перенести Raspberry Pi в более контролируемую среду. Настройте избавленние автоматизации и мониторинг с алертами для предотвращения будущих сбоев. Убедитесь, что все настройки и обновления программного обеспечения соответствуют рекомендуемым практикам для безопасности и работоспособности системы.

Эти шаги помогут вам лучше разобраться с возникшей проблемой и обеспечат стабильную работу системы. Если проблема сохраняется, можно рассмотреть возможность консультации с сетевыми администраторами или специалистами по Linux для проведения более детального анализа.

Оцените материал
Добавить комментарий

Капча загружается...