Как безопасно передать временный доступ к серверу специалисту
Если сайт, почта или приложение перестали работать, специалисту может понадобиться доступ к серверу. Но передавать основной пароль от root или личного аккаунта небезопасно.
Правильный вариант — создать отдельного временного пользователя, дать ему доступ только на время работ, при необходимости выдать sudo-права, а после завершения — отключить или удалить аккаунт.
Эту инструкцию можно использовать для серверов на Linux, чаще всего Ubuntu или Debian.
Если вы не уверены в команде — лучше сначала уточните у специалиста. Ошибка в настройках SSH, sudo или firewall может привести к потере доступа к серверу.
Что понадобится заранее
Перед началом подготовьте:
1. IP-адрес сервера.
2. Доступ к серверу под root или пользователем с sudo.
3. Публичный SSH-ключ специалиста.
4. Понимание задачи: что именно нужно проверить или настроить.
Публичный SSH-ключ специалиста обычно выглядит примерно так:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ... user@example
или так:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... user@example
Это не пароль. Публичный ключ можно передавать. Секретный приватный ключ передавать нельзя.
Шаг 1. Подключитесь к своему серверу
Откройте терминал и подключитесь к серверу под своим текущим пользователем.
Пример:
ssh root@IP_СЕРВЕРА
или:
ssh user@IP_СЕРВЕРА
Если SSH работает на нестандартном порту, команда будет такой:
ssh -p 2222 user@IP_СЕРВЕРА
Что ожидать:
user@server:~$
или:
root@server:~#
Если вы видите такую строку — вы на сервере и можете выполнять команды.
Шаг 2. Создайте временного пользователя
Создадим отдельного пользователя, например support.
Если вы зашли под обычным пользователем с sudo, выполните:
sudo adduser support
Если вы зашли под root, можно выполнить без sudo:
adduser support
Система попросит ввести пароль для нового пользователя:
New password:
Retype new password:
Введите временный пароль. При вводе пароль может не отображаться — это нормально.
Дальше система может спросить имя, телефон и другие поля. Их можно оставить пустыми, просто нажимая Enter.
В конце появится вопрос:
Is the information correct? [Y/n]
Введите:
Y
Что ожидать после успешного создания:
Adding user `support' ...
Adding new group `support' ...
Creating home directory `/home/support' ...
Пользователь support создан.
Шаг 3. Добавьте SSH-ключ специалиста
Теперь нужно разрешить специалисту подключаться по SSH-ключу.
Создайте папку .ssh для нового пользователя:
sudo mkdir -p /home/support/.ssh
Откройте файл authorized_keys:
sudo nano /home/support/.ssh/authorized_keys
Вставьте туда публичный SSH-ключ специалиста одной строкой.
Пример:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... specialist@example
Сохраните файл:
Ctrl + O — сохранить.
Enter — подтвердить имя файла.
Ctrl + X — выйти из редактора.
Теперь выставьте правильные права:
sudo chown -R support:support /home/support/.ssh
sudo chmod 700 /home/support/.ssh
sudo chmod 600 /home/support/.ssh/authorized_keys
Что ожидать:
Если команды ничего не вывели — это нормально. В Linux многие команды при успешном выполнении не показывают сообщений.
Проверить файл можно так:
sudo ls -la /home/support/.ssh
Пример нормального результата:
drwx------ 2 support support 4096 Jun 12 12:00 .
-rw------- 1 support support 120 Jun 12 12:00 authorized_keys
Шаг 4. Проверьте, нужен ли специалисту sudo
Для простой проверки логов или файлов sudo может быть не нужен. Но для настройки сервера sudo часто требуется.
Sudo нужен, если специалист должен:
перезапускать Nginx или Apache;
настраивать PHP-FPM;
работать с MySQL как администратор;
менять конфиги в /etc;
устанавливать пакеты;
настраивать SSL-сертификаты;
менять firewall;
исправлять системные ошибки.
Важно понимать: пользователь с sudo может выполнять почти любые административные действия на сервере. Поэтому sudo лучше выдавать только временному пользователю и только на время работ.
Шаг 5. Если sudo нужен — добавьте пользователя в группу sudo
Чтобы специалист мог выполнять административные команды, добавьте пользователя support в группу sudo:
sudo usermod -aG sudo support
Что ожидать:
Обычно команда ничего не выводит. Это нормально.
Проверить можно так:
groups support
Нормальный результат должен содержать sudo:
support : support sudo
Теперь пользователь support сможет выполнять команды через sudo.
Например:
sudo systemctl status nginx
Шаг 6. Если sudo просит пароль
Обычно sudo попросит пароль пользователя support:
[sudo] password for support:
Это не root-пароль. Это пароль временного пользователя support, который вы создали на шаге 2.
Если вы выдаёте специалисту sudo-доступ, передайте ему временный пароль от support безопасным способом. Например, не в общем чате, а отдельным сообщением или через защищённый менеджер паролей.
После завершения работ этот пароль всё равно нужно отключить вместе с временным аккаунтом.
Вариант: sudo без пароля, если так удобнее
Иногда специалисту удобнее работать без постоянного ввода пароля для sudo. Это можно сделать, но только если вы доверяете специалисту и понимаете риск.
Создайте отдельное sudoers-правило:
sudo visudo -f /etc/sudoers.d/support-temp
Вставьте строку:
support ALL=(ALL:ALL) NOPASSWD: ALL
Сохраните файл:
Ctrl + O
Enter
Ctrl + X
Проверьте права файла:
sudo chmod 440 /etc/sudoers.d/support-temp
Что это значит:
Пользователь support сможет выполнять sudo-команды без ввода пароля.
Например:
sudo whoami
Ожидаемый результат:
root
Такой вариант удобен для работ, но его обязательно нужно удалить после завершения настройки.
Шаг 7. Проверьте SSH-сервис и порт
Проверьте, работает ли SSH:
sudo systemctl status ssh
Ожидаемый результат:
Active: active (running)
Если команда не сработала, попробуйте:
sudo systemctl status sshd
Чтобы узнать IP сервера, можно выполнить:
hostname -I
Пример результата:
185.91.179.71
Чтобы посмотреть, на каком порту работает SSH:
sudo grep -i "^Port" /etc/ssh/sshd_config
Если ничего не вывело, чаще всего используется стандартный порт:
22
Шаг 8. Что отправить специалисту
После создания доступа отправьте специалисту такие данные:
IP сервера: 185.91.179.71
SSH-порт: 22
Пользователь: support
Доступ: по SSH-ключу
Sudo: да / нет
Задача: проверить Nginx, SSL, PHP, базу данных и ошибку сайта
Если вы создали временный пароль для sudo, отправьте его отдельно:
Временный пароль пользователя support: ********
Не отправляйте:
root-пароль;
пароль от личного кабинета регистратора домена;
пароль от основной почты;
доступы к банкам, платёжкам и личным аккаунтам, если это не нужно для задачи.
Шаг 9. Как специалист будет подключаться
Специалист подключится примерно такой командой:
ssh support@185.91.179.71
Если SSH-порт нестандартный:
ssh -p 2222 support@185.91.179.71
Если всё настроено правильно, специалист попадёт на сервер и увидит примерно такую строку:
support@server:~$
Если ему выдан sudo, он сможет проверить права:
sudo whoami
Ожидаемый ответ:
root
Это означает, что административные права работают.
Шаг 10. Что специалист обычно проверяет
После входа специалист может проверить состояние основных сервисов.
Например:
sudo systemctl status nginx
sudo systemctl status php8.3-fpm
sudo systemctl status mysql
df -h
free -h
Что можно увидеть:
Active: active (running)
Это означает, что сервис работает.
Если видно:
Active: failed
или:
No space left on device
значит найдена возможная причина проблемы.
Логи Nginx обычно смотрят так:
sudo tail -n 100 /var/log/nginx/error.log
Логи помогают понять, почему сайт отдаёт ошибку 500, не видит PHP, не подключается к базе или не может открыть нужный файл.
Шаг 11. Как контролировать, кто подключался
Посмотреть активных пользователей можно командой:
who
Пример результата:
support pts/0 2026-06-12 12:30
Посмотреть последние входы:
last -a | head
Пример результата:
support pts/0 Fri Jun 12 12:30 still logged in 185.91.179.10
root pts/1 Fri Jun 12 10:00 - 10:20 185.91.179.20
Это помогает понять, был ли вход на сервер и с какого IP.
Шаг 12. После работ заберите sudo-права
Если вы хотите оставить пользователя support, но убрать административные права, выполните:
sudo deluser support sudo
или:
sudo gpasswd -d support sudo
Что ожидать:
Removing user `support' from group `sudo' ...
Проверьте:
groups support
Если sudo больше нет в списке, административные права убраны.
Шаг 13. Если включали sudo без пароля — обязательно отключите
Если вы создавали файл:
/etc/sudoers.d/support-temp
удалите его:
sudo rm /etc/sudoers.d/support-temp
Проверьте sudoers:
sudo visudo -c
Ожидаемый результат:
/etc/sudoers: parsed OK
/etc/sudoers.d/support-temp: parsed OK
Если файл уже удалён, строки про support-temp может не быть. Главное, чтобы было:
parsed OK
Шаг 14. Полностью удалите временного пользователя
Когда работы закончены, лучше полностью удалить временный аккаунт:
sudo userdel -r support
Что ожидать:
Обычно команда ничего не выводит. Это нормально.
Проверить удаление можно так:
id support
Ожидаемый результат:
id: ‘support’: no such user
Это значит, что временный пользователь удалён.
Шаг 15. Если не хотите удалять пользователя, удалите SSH-ключ
Можно оставить аккаунт, но удалить ключ доступа:
sudo rm /home/support/.ssh/authorized_keys
После этого подключиться по старому SSH-ключу уже не получится.
Но для временного доступа безопаснее полностью удалить пользователя.
Короткая версия для клиента
Если специалист попросил доступ к серверу, безопасная схема такая:
1. Создать отдельного пользователя support.
2. Добавить SSH-ключ специалиста в authorized_keys.
3. Если нужно администрирование — временно добавить support в sudo.
4. Передать IP, порт, логин и задачу.
5. Не передавать root-пароль.
6. После работ удалить пользователя support.
Готовый текст, который можно отправить специалисту
Здравствуйте.
Создал временный доступ к серверу:
IP: 185.91.179.71
Порт SSH: 22
Пользователь: support
Доступ: по SSH-ключу
Sudo-права: да
Задача:
Проверить сайт, Nginx, SSL, PHP, базу данных и найти причину ошибки.
После завершения работ прошу написать коротко:
1. В чём была причина проблемы.
2. Какие файлы и настройки менялись.
3. Какие сервисы перезапускались.
4. Что рекомендуется сделать дополнительно.
Когда лучше не делать самому
Если вы не уверены, как создать пользователя, настроить SSH-ключ или выдать sudo, лучше не экспериментировать на рабочем сервере. Неправильная настройка может закрыть доступ к серверу или создать дыру в безопасности.
В DevShtab мы можем подсказать, какой доступ нужен именно для вашей задачи, безопасно подключиться, проверить сервер, настроить сайт, почту, SSL, Nginx, PHP, базу данных и после работ помочь отключить временный доступ.
Главная идея простая: специалисту не нужен ваш root-пароль. Ему нужен временный доступ, понятная задача и права только на время работы.