TeaHostПроект перерос одного человека: появился модератор, который сидит вечерами, знакомый, собирающий сборку модов, и билдер, которому нужно заливать схематики. Дать всем один пароль от панели — быстро и очень плохо. Доступ к серверу для команды правильно раздавать субаккаунтами: у каждого своя учётка со своим набором прав и своим следом в логах. Разберём, кому что выдавать и как не оставить чёрный ход после ухода человека.
Почему общий пароль — плохая идея
Аргументы против него не абстрактные, а очень практические.
Нет ответственности. Когда мир снесён, а доступ был у пятерых, выяснить, кто и что нажал, невозможно. С отдельными учётками в логах панели видно, кто запускал, кто удалял файлы, кто восстанавливал бэкап.
Нет градаций. Модератору нужно только банить и читать чат, а с общим паролем он получает и файловый менеджер, и биллинг, и кнопку удаления сервера. Один неверный клик — и вечер испорчен всем.
Уход = смена пароля для всех. Человек ушёл из команды, и вы меняете пароль, после чего вручную рассылаете новый оставшимся. Через полгода никто уже не помнит, у кого он есть.
Пароль утекает. Он пересылается в личке, сохраняется в браузерах, попадает в скриншоты. Один общий секрет на пятерых утечёт с вероятностью, близкой к единице.
Как выдать доступ к серверу для команды
В панели Pterodactyl, на которой работает TeaHost, субаккаунты живут во вкладке сервера Users. Схема стандартная: вы приглашаете человека по email, он создаёт свой пароль, вы отмечаете галочками, что ему можно.
- Откройте раздел управления пользователями сервера.
- Добавьте пользователя, указав его почту. Именно его, не общую — это его личная учётка.
- Отметьте разрешения по принципу минимума: только то, без чего человек не сделает свою работу.
- Сохраните. Приглашённый получит письмо и заведёт себе пароль сам — вы его не знаете и знать не должны.
- Попросите включить двухфакторную аутентификацию, если панель её поддерживает.
Субаккаунт даёт доступ только к тому серверу, где вы его создали. Биллинг, оплата и удаление сервера остаются за владельцем — и это правильно.
Какие права кому
Разложим по типичным ролям:
| Право | Модератор | Разработчик | Билдер | Совладелец |
|---|---|---|---|---|
| Просмотр консоли | да | да | нет | да |
| Команды в консоль | по ситуации, часто хватает игровых прав | да | нет | да |
| Файлы и SFTP | нет | да | да, с оглядкой | да |
| Запуск, остановка, перезапуск | нет | да | нет | да |
| Создание бэкапов | нет | да | нет | да |
| Удаление бэкапов | нет | нет, оставьте себе | нет | по договорённости |
| Порты, расписания, настройки запуска | нет | нет | нет | да |
| Биллинг и удаление сервера | нет | нет | нет | нет, только владелец |
Полный доступ к файлам равен полному контролю над сервером — помните об этом, выдавая его билдеру.
Общий принцип: права выдаются под задачу, а не «на всякий случай». Расширить набор можно за минуту, когда понадобится.
Панель и игра — это разные права
Частая путаница. Доступ в панель и админка в игре — два независимых механизма.
Модератору, который банит нарушителей в чате, панель обычно вообще не нужна: ему нужны игровые права. В Minecraft это группы LuckPerms, в Rust — записи в users.cfg и права Oxide, в CS2 — конфигурация админов плагина. Разграничение внутри игры описано в статьях про настройку LuckPerms и права операторов, а для Rust — в материале про админ-команды.
Практическое правило: сначала пробуйте решить задачу игровыми правами. Панель выдавайте только тем, кому реально нужно трогать файлы и процесс сервера.
RCON и SFTP: отдельная история
Два доступа, которые ломают всю схему разграничения, если раздать их бездумно.
RCON — это консоль с максимальными правами и одним общим паролем на всех. Персональных RCON-доступов не бывает. Если вы выдали пароль трём людям, вы фактически выдали им права владельца консоли без всякого разграничения и следов в логах. Держите RCON для ботов и скриптов, а людям давайте консоль через субаккаунт панели; подробности — в статье про подключение по RCON.
SFTP в большинстве панелей привязан к учётке пользователя: субаккаунт с правом на файлы получает и свой SFTP-логин. Это удобно и безопасно. А вот если панель выдаёт один общий SFTP-доступ — обращайтесь с ним как с паролем владельца. Настройка клиентов описана в статье про подключение по SFTP.
Когда человек уходит
Момент, который откладывают, а потом забывают. Порядок на пятнадцать минут:
- Удалите субаккаунт в панели — не отключите, а удалите.
- Смените пароль RCON, если человек его знал.
- Снимите игровые права: группу в LuckPerms, запись в
users.cfg, роль в Discord. - Проверьте файлы на предмет сюрпризов: посторонние jar в
plugins/, изменённые скрипты запуска, новые задачи в планировщике. - Просмотрите логи панели за последние дни — не было ли массового скачивания или удаления.
Последние два пункта звучат параноидально ровно до первого случая, когда обиженный экс-модератор оставил себе плагин с бэкдором.
Гигиена доступов
Несколько привычек, которые стоят недорого:
- Раз в квартал пересматривайте список пользователей: половина обычно уже неактуальна.
- Не заводите учётки «на общую почту команды» — это тот же общий пароль, только сбоку.
- Требуйте двухфакторную аутентификацию хотя бы у тех, кто имеет доступ к файлам.
- Владельческий аккаунт держите только у себя и не используйте его для повседневной работы, если есть возможность завести субаккаунт себе же.
- Ограничивайте право удалять бэкапы — это последняя линия обороны, и она должна быть только у вас.
Раздайте роли аккуратно один раз, и команда будет работать быстрее, а вы — спокойнее спать. Тарифы с панелью Pterodactyl — посмотреть можно тут.