Permission denied при деплое

MAATRIX

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

Первый шаг: определяем, где именно отказ

Permission denied при деплое бывает трёх видов, и первое, что нужно сделать, — понять, какой из них ваш. Первый — отказ при SSH-подключении (Permission denied (publickey)): деплой вообще не может зайти на сервер. Второй — отказ при записи файлов: зашли, но не можем скопировать или перезаписать. Третий — отказ при выполнении команд (перезапуск сервиса, установка пакетов): не хватает прав sudo. Посмотрите на точную строку ошибки — в ней есть подсказка:

# запустить деплой/подключение с подробным логом SSH
ssh -v deploy@СЕРВЕР
# если ошибка при записи — проверить права целевого каталога
ls -ld /var/www/app
namei -l /var/www/app/current

Строка Permission denied (publickey) — это SSH, проблема доступа на вход. Permission denied при копировании файла — это права на каталог назначения. Отказ на команде вроде systemctl restart — это sudo. Определив вид, вы сразу знаете, в какой из следующих секций ваше решение, и не будете чинить SSH, когда дело в правах на папку.

Отказ на этапе SSH

Если деплой не может подключиться, причина в аутентификации. Чаще всего деплой-система (CI, скрипт) ходит по SSH-ключу, и этот ключ либо не добавлен на сервер, либо добавлен не тому пользователю. Проверьте, что публичный ключ деплой-пользователя лежит в его authorized_keys, и что права на каталог .ssh корректны:

# на сервере, под деплой-пользователем
ls -la ~/.ssh
# права должны быть строго такими
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
cat ~/.ssh/authorized_keys   # должен содержать публичный ключ CI/деплоя

Частая незаметная причина — именно права: если .ssh или authorized_keys доступны на запись группе или всем, SSH из соображений безопасности игнорирует ключ и выдаёт Permission denied, даже когда ключ правильный. Нужны 700 на каталог и 600 на файл. Проверьте и то, под каким пользователем подключается деплой: ключ, добавленный root, не пустит пользователя deploy, и наоборот. Запуск ssh -v покажет, предлагается ли ключ и на каком этапе сервер его отвергает.

Отказ при записи файлов

Зашли на сервер, но деплой не может записать файлы — значит, у пользователя нет прав на целевой каталог. Типично, когда каталог сайта принадлежит root или веб-серверу, а деплой идёт под отдельным пользователем deploy. Решение — сделать деплой-пользователя владельцем каталога выкладки, а не раздавать всем права на запись:

# кто владелец и какие права
ls -ld /var/www/app
# отдать каталог деплой-пользователю
chown -R deploy:www-data /var/www/app
# права: владельцу запись, группе чтение/выполнение
chmod -R 750 /var/www/app

Не поддавайтесь искушению решить проблему через chmod 777 — это открывает каталог на запись вообще всем и является дырой в безопасности, особенно для веб-доступного каталога. Правильный путь — точная настройка владельца и группы. Продумайте связку: деплой-пользователь владеет файлами и пишет их, веб-сервер входит в группу и читает. Так и деплой проходит, и права остаются безопасными. Команда namei -l по пути помогает увидеть, на каком именно каталоге в цепочке теряется доступ.

Отказ при выполнении команд (sudo)

Третий случай — деплой скопировал файлы, но падает на команде, требующей прав root: перезапуск сервиса, установка пакета, перезагрузка Nginx. Давать деплой-пользователю полный root небезопасно и не нужно. Правильное решение — разрешить ему через sudo только конкретные команды, без пароля, чтобы автоматический деплой не завис на запросе пароля:

# в файле /etc/sudoers.d/deploy (правьте через visudo)
deploy ALL=(ALL) NOPASSWD: /bin/systemctl restart myapp, /usr/sbin/nginx -s reload

Такой подход даёт деплою ровно те права, что нужны для выкладки, и ни на грамм больше — принцип наименьших привилегий в действии. Если деплой падал с запросом пароля sudo в неинтерактивной сессии, NOPASSWD для разрешённых команд решает это. Никогда не прописывайте деплою NOPASSWD: ALL — это эквивалент раздачи root и сводит на нет всю безопасность. Перечисляйте команды поимённо, и компрометация деплой-ключа не даст атакующему полный контроль над сервером.

Права после деплоя: владелец и веб-сервер

Отдельная тонкость, из-за которой сайт ломается уже после успешного деплоя, — несоответствие владельца файлов и пользователя веб-сервера. Файлы выложены деплой-пользователем, а Nginx или PHP-FPM работают под своим пользователем (www-data) и не могут прочитать то, что им нужно, или записать в каталоги загрузок и кэша. В логах веб-сервера — permission denied.

Решается это продуманной схемой владения: код принадлежит деплой-пользователю и группе веб-сервера с правами на чтение, а каталоги, куда пишет само приложение (загрузки, кэш, логи), — доступны на запись веб-серверу. Разделяйте «код только для чтения» и «данные для записи»: это и безопаснее, и избавляет от плавающих ошибок доступа. После деплоя полезно автоматически выставлять корректные права, чтобы не ловить рассогласование вручную при каждой выкладке.

Профилактика: настраиваем деплой один раз правильно

Чтобы Permission denied не всплывал при каждой выкладке, настройте доступ системно с самого начала. Заведите отдельного деплой-пользователя со своим SSH-ключом — не деплойте под root. Сделайте его владельцем каталога выкладки с безопасными правами (750), включите веб-сервер в нужную группу. Разрешите через sudo только конкретные команды деплоя без пароля.

• Отдельный деплой-пользователь с ключом, а не root и не пароль.
• Владелец каталога — деплой-пользователь, права 750, а не 777.
• Веб-сервер в группе на чтение кода и на запись в каталоги данных.
• Sudo только для перечисленных команд с NOPASSWD, без ALL.
• Проверка прав .ssh: 700 на каталог, 600 на authorized_keys.

Полный контроль над пользователями, правами и sudo даёт собственный сервер с root-доступом. У MAATRIX VPS для деплоя доступны в локациях RU, US и UK, с оплатой из России картой или криптой. Когда вы настраиваете доступ один раз по принципу наименьших привилегий, деплой проходит автоматически и безопасно, а Permission denied остаётся в прошлом.

Частые вопросы