Что делать, если нет доступа к виртуальной машине (по SSH)?

Мои действия зависят от среды (облако/on-premise) и доступных инструментов.

В облачной среде (AWS EC2, GCP Compute Engine, Azure VM):

1. Проверю статус ВМ в консоли. Убеждаюсь, что инстанс в состоянии running, а не stopped или terminated.
2. Использую встроенную консоль восстановления. Это ключевой инструмент:
   • AWS: EC2 Instance Connect или Session Manager (если на ВМ установлен SSM Agent).
   • GCP: Serial console.
   • Azure: Serial console или Run Command. Через них можно проверить сеть, демоны (например, sshd), логи (/var/log/auth.log, /var/log/secure) и исправить конфигурацию SSH.
3. Проверю правила безопасности. Убеждаюсь, что Security Group/Network ACL разрешает входящие подключения на порт 22 с моего IP-адреса.
4. Подключу диск к другой ВМ. В крайнем случае, если файловая система повреждена, создам снапшот диска и подключу его к другой, рабочей ВМ для анализа и восстановления критичных конфигов.

В on-premise среде (vSphere, KVM, Hyper-V):

1. Проверю доступ через гипервизор. Подключусь к консоли ВМ напрямую через vSphere Client или Virt-Manager, чтобы обойти проблемы с сетью.
2. Проверю сетевое подключение хоста. Убежусь, что физический хост, на котором работает ВМ, имеет связь с сетью.
3. Восстановлюсь из бэкапа. Если ВМ критична и консоль не помогает, разверну её из последней успешной резервной копии.

Общая диагностика с другой машины в той же сети:

# Проверяем, доступен ли порт 22
nc -zv <IP_VM> 22
# Если порт закрыт, проверяем, отвечает ли ВМ вообще (ARP, ping)
arp -a | grep <IP_VM>
ping -c 2 <IP_VM>