Ситуация: вы поручаете AI-агенту настроить сервер. Он ставит fail2ban, проверяет вход по ключу, убеждается, что пароль отключён, и делает ещё пару тестовых попыток. На пятой неудачной попытке fail2ban банит IP, с которого идёт подключение. Это IP вашего ноутбука, на котором работает агент. В итоге все команды падают по таймауту, а вы ищете веб-консоль в панели провайдера. Знакомо? В бенчмарке одного из агентов такая самоблокировка случилась в 7 прогонах из 60 — модель просто не знала, что свой IP нужно добавить в ignoreip до первого запуска fail2ban. Эта статья о том, как выстроить процесс, чтобы агент с root-правами не отрезал вам доступ, и какие шаги стоит предпринять до, во время и после его работы.

Почему агент с root опасен именно для доступа

Агент не злонамерен — он оптимизирует задачу. Если вы просите «настроить безопасность», он может ужесточить правила SSH, включить фаервол или настроить бан по неудачным попыткам. Проблема в том, что агент не всегда осознаёт последствия для собственного канала связи. Он может изменить порт SSH, отключить парольную аутентификацию, не проверив, что ключ работает, или добавить правило, которое блокирует его же IP. В отличие от человека, агент не испытывает дискомфорта от потери связи — он просто продолжает выполнять команды, которые уже не проходят. Поэтому защита должна быть внешней по отношению к агенту: вы не можете полагаться на его здравый смысл, нужны технические ограничители.

Шаги до первого запуска агента

Прежде чем дать агенту root, выполните несколько действий. Во-первых, убедитесь, что у вас есть альтернативный способ входа: веб-консоль провайдера, IPMI/KVM или последовательный порт. Проверьте, что вы можете в неё зайти и что там есть работающий шелл. Во-вторых, создайте отдельного пользователя с sudo и настройте для него вход по ключу — не давайте агенту работать напрямую под root без необходимости. В-третьих, сделайте снапшот или бэкап системы, чтобы можно было откатиться. В-четвёртых, настройте ignoreip в fail2ban (если он уже установлен) или добавьте свой IP в белый список фаервола до того, как агент начнёт что-то менять. И наконец, зафиксируйте текущие настройки SSH в отдельном файле, чтобы агент мог их сравнить, а вы — восстановить.

  • Проверьте доступ к веб-консоли провайдера и убедитесь, что она работает.
  • Создайте резервного пользователя с sudo и ключом.
  • Сделайте снапшот VPS или бэкап критичных конфигов.
  • Добавьте свой IP в ignoreip fail2ban и в белый список фаервола.
  • Сохраните копию текущих конфигов SSH и фаервола.

Как ограничить агента во время работы

Даже с подготовкой агент может сделать что-то неожиданное. Чтобы снизить риск, используйте подход с автоматическим откатом: перед каждым изменением конфигурации агент должен создать точку восстановления, а после — проверить, что доступ не потерян. Если проверка не проходит, изменения откатываются. Это можно реализовать через простые скрипты: например, перед изменением /etc/ssh/sshd_config скопировать файл в /etc/ssh/sshd_config.bak и после перезапуска sshd выполнить тестовое подключение по ключу. Если подключение не удаётся, вернуть бэкап и перезапустить сервис. Также стоит ограничить агента работой в отдельной сессии tmux или screen, чтобы разрыв связи не убил процесс, и использовать таймауты на команды, чтобы агент не завис навсегда.

Ещё один приём — давать агенту не root, а пользователя с ограниченными sudo-правами на конкретные команды. Например, разрешить только systemctl restart sshd и редактирование файлов в /etc/fail2ban, но не полный доступ. Это сложнее настроить, но снижает вероятность катастрофы. Если же без root не обойтись, хотя бы запускайте агента в контейнере или на отдельной машине, которая не является вашим единственным входом на сервер.

Типичные ошибки и как их избежать

Самая частая ошибка — забыть про ignoreip. Агент тестирует вход по паролю, fail2ban банит его IP, и всё останавливается. Решение: до запуска fail2ban добавьте IP агента (и свой) в ignoreip в /etc/fail2ban/jail.local. Вторая ошибка — изменение порта SSH без обновления правил фаервола. Агент меняет Port 22 на 2222, но забывает открыть новый порт, и доступ теряется. Решение: сначала добавьте правило для нового порта, проверьте подключение, и только потом закрывайте старый. Третья ошибка — отключение парольной аутентификации до проверки ключа. Агент ставит PasswordAuthentication no, но ключ не настроен, и вы остаётесь без входа. Решение: всегда проверяйте вход по ключу в новой сессии перед отключением пароля. Четвёртая ошибка — отсутствие бэкапа конфигов. Если что-то пошло не так, вы не сможете быстро восстановиться. Решение: автоматический бэкап перед каждым изменением.

  • Не добавляйте свой IP в ignoreip — и fail2ban заблокирует вас.
  • Меняйте порт SSH, не открыв его в фаерволе.
  • Отключайте пароль, не проверив ключ.
  • Не делайте бэкап конфигов перед изменениями.
  • Запускайте агента без альтернативного доступа к серверу.

Что делать, если доступ уже потерян

Если агент всё-таки заблокировал доступ, не паникуйте. Первым делом используйте веб-консоль провайдера или IPMI. Если это недоступно, проверьте, не заблокирован ли ваш IP на уровне фаервола провайдера — иногда можно снять блокировку через панель управления. Если есть снапшот, откатитесь к нему. В крайнем случае обратитесь в поддержку провайдера с просьбой восстановить доступ или переустановить систему. Чтобы не доводить до этого, всегда имейте запасной путь: второй SSH-ключ, резервного пользователя, альтернативный порт. И помните: агент — это инструмент, а не администратор. Ответственность за доступ лежит на вас, поэтому ключевые изменения лучше делать вручную или под строгим контролем.

В итоге, работа с агентом на VPS требует дисциплины: подготовка, ограничение прав, автоматический откат и проверка доступа после каждого шага. Не позволяйте агенту работать без присмотра с root-правами, если это не необходимо. И всегда имейте план Б.