Сервер для удалённой команды: SSH, RDP и общие ресурсы

Общий сервер для удалённой работы решает сразу несколько проблем распределённой команды: единое окружение для разработки, общие файлы без пересылки архивов в мессенджерах, доступ к корпоративным сервисам из любой точки мира. Вместо того чтобы каждому настраивать своё окружение и синхронизировать версии инструментов, команда подключается к одному VPS — по SSH для консольной работы или по RDP, если нужен графический рабочий стол. В этой статье разберём, как превратить обычный VPS в корпоративный сервер: создадим пользователей с доступом по SSH-ключам, поднимем xRDP, настроим общие папки и посчитаем, сколько ресурсов нужно на человека.

Зачем команде свой сервер, а не набор SaaS-подписок

Типичный сценарий: команда из пяти человек платит за облачную IDE, файловое хранилище, VPN-сервис и пару инструментов «по подписке на пользователя». Суммарно выходит несколько тысяч рублей в месяц, при этом данные лежат у третьих сторон, а каждый сервис живёт по своим правилам.

Один VPS закрывает большинство этих задач:

• Единое окружение разработки. Все работают на одной версии компилятора, интерпретатора и библиотек — «у меня локально работает» перестаёт быть аргументом.
• Общие файлы и ресурсы. Проектные документы, датасеты, сборки — в одной директории с групповыми правами, а не в десяти копиях по ноутбукам.
• Тяжёлые задачи на сервере. Сборка проекта, обработка данных или тесты крутятся на 12–20 ядрах сервера, а не греют ноутбук сотрудника.
• Контроль доступа. Сотрудник уволился — вы блокируете одну учётную запись, а не вспоминаете, где у него остались пароли.
• Предсказуемая цена. Сервер стоит фиксированно и не дорожает с каждым новым инструментом.

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

Сколько ресурсов нужно: считаем по 2 ГБ RAM на пользователя

Практическое правило для сервера удалённой команды: ~2 ГБ RAM на каждого активного пользователя плюс 1–2 ГБ на систему и общие службы. «Активный» — тот, кто прямо сейчас держит открытую сессию и что-то делает: собирает проект, работает в IDE через SSH, сидит в графической сессии xRDP. Если человек только читает файлы по SFTP, его вклад в нагрузку минимален.

Консольная работа по SSH заметно легче графической: терминальная сессия с vim и парой утилит укладывается в сотни мегабайт, а вот рабочий стол XFCE через xRDP с браузером легко занимает 1,5–2,5 ГБ. Поэтому если вся команда работает через удалённый рабочий стол, закладывайте по верхней границе.

NVMe-диск здесь не маркетинг, а ощутимая разница: когда пять человек одновременно собирают проекты и открывают файлы, именно скорость случайного чтения диска определяет, «летает» сервер или «задумывается». Начать можно с младшего тарифа: у Cheap-Host апгрейд CPU, RAM и диска выполняется без потери данных, так что рост команды не потребует переезда.

SSH-доступ для команды: пользователи и вход по ключам

Базовый принцип: один сотрудник — один Linux-пользователь — один SSH-ключ. Никаких общих паролей «на всех» и работы под root.

Шаг 1. Создаём группу и пользователей

sudo groupadd developers
sudo adduser anna
sudo usermod -aG developers anna

Повторите для каждого сотрудника. Тем, кому нужны административные права, дополнительно выдайте sudo: sudo usermod -aG sudo anna. Подробнее о том, почему не стоит работать под root, — в статье о создании пользователя с sudo.

Шаг 2. Прописываем публичные ключи

Каждый сотрудник генерирует пару ключей на своём компьютере (ssh-keygen -t ed25519) и присылает вам публичную часть. Вы добавляете её на сервер:

sudo mkdir -p /home/anna/.ssh
echo "ssh-ed25519 AAAA...ключ... anna@laptop" | sudo tee -a /home/anna/.ssh/authorized_keys
sudo chmod 700 /home/anna/.ssh
sudo chmod 600 /home/anna/.ssh/authorized_keys
sudo chown -R anna:anna /home/anna/.ssh

Пошаговая инструкция с генерацией ключей на Windows и macOS — в отдельном материале про SSH-ключи вместо пароля.

Шаг 3. Отключаем пароли и root-вход

Когда все ключи добавлены и проверены, ужесточаем конфигурацию SSH в /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication no
AllowGroups developers sudo

sudo systemctl restart ssh

Теперь подобрать пароль невозможно в принципе — входа по паролю нет, а список допущенных групп ограничен. Директива AllowGroups удобна и при офбординге: убрали пользователя из группы — доступ закрыт.

Графический доступ: настраиваем xRDP

Части команды консоли недостаточно: дизайнеру, аналитику или бухгалтеру нужен привычный рабочий стол. Для этого на Linux VPS ставится xRDP — сервер протокола RDP, к которому подключаются штатным клиентом «Подключение к удалённому рабочему столу» из Windows (или Remmina/Microsoft Remote Desktop на Linux и macOS).

sudo apt update
sudo apt install -y xrdp xfce4 xfce4-goodies
echo "startxfce4" | sudo tee /home/anna/.xsession
sudo chown anna:anna /home/anna/.xsession
sudo systemctl enable --now xrdp

XFCE выбран не случайно: это лёгкое окружение, которое экономит память — критично, когда сессий несколько. Каждый пользователь подключается под своей учётной записью и получает собственный изолированный рабочий стол; одновременные сессии разных пользователей работают параллельно.

Важно про безопасность: не открывайте порт 3389 всему интернету — его сканируют боты круглосуточно. Минимум — ограничьте доступ по IP через UFW:

sudo ufw allow from 203.0.113.10 to any port 3389 proto tcp

Лучший вариант — выпустить RDP только внутрь VPN-туннеля: сотрудники сначала подключаются к WireGuard на этом же VPS, а уже через туннель — к рабочему столу. Снаружи сервер отвечает только по SSH. Тонкости настройки xRDP, включая типовые проблемы с чёрным экраном, разобраны в статье про удалённый рабочий стол xRDP.

Общие папки: файлы команды в одном месте

Самый простой и надёжный механизм общих файлов для тех, кто работает на самом сервере, — директория с групповыми правами:

sudo groupadd team
sudo mkdir -p /srv/shared
sudo chown root:team /srv/shared
sudo chmod 2770 /srv/shared
sudo usermod -aG team anna

Разберём права 2770: владелец и группа имеют полный доступ, остальные — никакого, а бит setgid (двойка впереди) гарантирует, что каждый новый файл внутри автоматически получит группу team. Без него файлы создавались бы с личной группой автора, и коллеги не смогли бы их редактировать.

Когда групповой папки мало:

• Samba — если файлы нужно монтировать как сетевой диск в Windows-проводнике на локальных машинах сотрудников (разумно — тоже только через VPN).
• Nextcloud — если нужны веб-интерфейс, версии файлов, синхронизация и доступ с телефона. Это полноценная замена облачным дискам; развёртывание описано в статье про Nextcloud на VPS.

Гигиена корпоративного сервера

Сервер, на котором работает вся команда, — единая точка отказа, поэтому дисциплина обязательна:

1. Файрвол по принципу «закрыто всё, кроме нужного». Наружу — только SSH (в идеале на нестандартном порту) и порт VPN; RDP, Samba и панели — только внутри туннеля.
2. Fail2ban для автоматической блокировки перебора на открытых портах.
3. Регулярные бэкапы. Общая папка и домашние директории должны копироваться наружу по расписанию — на другой сервер или в S3-хранилище.
4. Обновления безопасности — включите unattended-upgrades, чтобы патчи ставились сами.
5. Аудит доступов раз в квартал: проверяйте /etc/passwd и ключи в authorized_keys — не осталось ли учёток ушедших сотрудников. Блокировка выполняется одной командой: sudo usermod -L -e 1 anna.

Отдельный плюс размещения в России для российской команды — низкий пинг: до московского сервера из большинства регионов РФ задержка составляет 10–50 мс, что важно для отзывчивости RDP-сессий.

FAQ

Сколько человек могут одновременно работать на одном VPS?

Ориентируйтесь на ~2 ГБ RAM на активного пользователя плюс 1–2 ГБ на систему и общие сервисы. На 16 ГБ комфортно работают 5–7 человек, на 32 ГБ — 12–15. Консольная работа по SSH легче, графические сессии xRDP — тяжелее.

Можно ли дать сотрудникам доступ без передачи пароля root?

Да, и только так и нужно: каждому — отдельный пользователь со своим SSH-ключом, root-вход отключён, sudo — только тем, кому необходимо. Уволившемуся сотруднику блокируется одна учётная запись, остальные работают дальше.

Безопасно ли открывать порт RDP (3389) в интернет?

Нет, это одна из главных целей ботов. Ограничьте порт файрволом по IP сотрудников или спрячьте RDP за VPN — снаружи сервер должен отвечать только по SSH.

Что выбрать для общих файлов: групповую папку, Samba или Nextcloud?

Работаете прямо на сервере — хватит директории с правами 2770. Нужен сетевой диск на локальных машинах — Samba через VPN. Нужны веб-интерфейс и синхронизация — Nextcloud.

Какой тариф взять для команды из 5 человек?

Для 4–7 активных пользователей — конфигурация 12 vCPU / 16 ГБ RAM, например Pro у Cheap-Host за 750 ₽/мес. Вырастете — тариф апгрейдится без потери данных.

Вывод

Сервер для удалённой работы команды собирается за один вечер: пользователи с SSH-ключами, xRDP для тех, кому нужен рабочий стол, общая папка с групповыми правами и VPN поверх всего этого. Дальше он просто работает, а вы управляете доступами из одной точки. Если для этой задачи нужен сервер — у Cheap-Host тариф Pro за 750 ₽/мес: 12 vCPU, 16 ГБ RAM, NVMe 128 ГБ, KVM с полным root, безлимитный трафик и выдача сервера за минуту. Тарифы — на cheap-host.onl, а если сомневаетесь в выборе конфигурации — поддержка 24/7 ответит без шаблонных отписок.