SSH и SFTP для сайта: отдельные доступы и проверка ключей

Редакция HOSTIO · Опубликовано 26.10.2026 · Обновлено 27.10.2026

Серверное оборудование в стойке дата-центра

Фото: panumas nikhomkhai / Pexels.

В материале

Как подготовить отдельный SSH/SFTP-доступ: сверить ключ сервера, различить публичный и закрытый ключ пользователя, проверить каталог и права, передать тестовый файл и отозвать доступ.

Уточните доступный режим

На shared-хостинге SSH может быть ограничен или выключен по умолчанию. Проверьте документацию и панель своего аккаунта. SFTP не следует путать с обычным FTP или FTPS: это разные протоколы, и настройки клиента должны соответствовать услуге.

Получите адрес, порт и пользователя из своего кабинета. Не используйте значения из чужого примера. Для подрядчика создайте отдельный доступ с минимальными правами, если продукт это позволяет. Доступ ко всему аккаунту не нужен для каждой операции с одним каталогом.

Проверьте сервер при первом соединении

Клиент показывает ключ сервера, чтобы отличать ожидаемую систему от подмены. Сверяйте отпечаток через доверенный канал провайдера или администратора. Не принимайте предупреждение о смене ключа автоматически: причиной может быть законная переустановка, но это требует проверки.

Сохранённое доверие относится к конкретному серверу и имени. Переезд или смена адреса должны быть документированы. Отключение проверки host key ради удобства убирает важную часть защиты соединения.

Организуйте пользовательский ключ

Пара состоит из публичного и закрытого ключа. Публичный добавляется разрешённым способом на сервер, закрытый остаётся у владельца. Не отправляйте закрытый ключ в поддержку и не добавляйте его в репозиторий. Защитите его подходящей парольной фразой и хранением.

Для разных людей используйте разные ключи. При завершении работ отзывается конкретный публичный ключ, а не меняется один общий секрет для всех. Если устройство потеряно или ключ раскрыт, удалите соответствующее разрешение и проверьте связанные доступы.

Различайте три объекта доверия

При подключении участвуют адрес сервера, его host key и учётная запись пользователя. Серверный ключ подтверждает ожидаемую сторону соединения; пользовательский ключ помогает серверу проверить ваш доступ. Добавление своего публичного ключа в панель не проверяет автоматически ключ самого сервера. Эти действия фиксируются отдельно, иначе легко принять чужую систему только потому, что клиент спросил пароль.

Объект Где берётся Что нельзя делать
Адрес и порт Из подтверждённого кабинета или у администратора Подставлять значения из чужого скриншота
Host key / fingerprint Из независимого доверенного канала Принимать неожиданную смену без проверки
Публичный ключ пользователя Из вашей созданной пары Путать с закрытым файлом
Закрытый ключ Хранится у владельца доступа Отправлять в поддержку или публиковать
Область прав Из задачи и модели услуги Выдавать весь аккаунт для одного каталога

Полученный из текущего неподтверждённого соединения отпечаток не становится независимым доказательством подлинности этого же соединения. Сверяйте его с заранее доверенным каналом поставщика. При законной переустановке сервера ключ может измениться, но решение принимают после подтверждения события, а не по привычке нажать «да».

Подготовьте отдельную пару и учтите совместимость

Алгоритм и способ хранения выбирают по поддержке сервера, клиента и правилам организации. Не перезаписывайте существующий ключ с тем же именем, не проверив его назначение. Если используете аппаратный носитель или агент, учитывайте предусмотренный процесс восстановления и отзыва. Для разных людей и автоматических сервисов нужны различимые полномочия.

ssh-keygen -l -f ./hostio-demo.pub
Пример просмотра отпечатка уже существующего публичного файла. hostio-demo.pub — учебное имя; команда не создаёт и не публикует новый доступ.

При создании пары используйте доверенный инструмент и защищённое хранение. Парольную фразу не помещайте в командную строку общего журнала. В реестре достаточно владельца, назначения, публичного отпечатка и срока. Закрытый ключ и резервная копия относятся к защищённому хранилищу. Пересылка файла с окончанием без .pub может раскрыть секрет, поэтому проверяйте содержимое и тип до передачи.

Первый рабочий сеанс

Шаг Контроль
Соединение Проверен ожидаемый сервер
Каталог Определён путь нужного проекта
Права Нет лишнего доступа к соседним данным
Передача Проверены файл, размер и место назначения
Изменение Есть исходная версия и способ возврата
Завершение Временные файлы и доступы учтены

Первый сеанс начинайте с чтения контекста

После подтверждённого подключения проверьте пользователя и текущий каталог до любой записи. На shared путь может находиться внутри ограниченного окружения, и видимый корень не обязательно совпадает с корнем ОС. Не делайте вывод о праве доступа к соседним проектам только по возможности войти. Проверяйте предоставленную область в рамках разрешённого собственного тестового каталога.

whoami
pwd
ls -ld .
Команды чтения контекста Unix-подобной среды. Вывод может содержать внутренние пути; не публикуйте его целиком без необходимости.

Для SFTP используйте подтверждённые адрес, порт и пользователя в клиенте, затем сравните удалённый путь с паспортом проекта. Командная оболочка может быть недоступна при разрешённом SFTP — это не обязательно ошибка. Не требуйте полноценный SSH, если задача ограничена передачей файла и услуга намеренно предоставляет только этот режим.

Проверьте передачу на безвредном файле

Сначала выберите согласованный тестовый каталог и небольшой файл без секретов. Проверьте имя, размер и содержимое после передачи, а при необходимости — контрольную сумму тем же поддерживаемым алгоритмом на обеих сторонах. Не заменяйте рабочую конфигурацию ради проверки соединения. Передача завершена только после чтения результата на целевой стороне.

  1. Подтвердите абсолютный или однозначный путь назначения.
  2. Сохраните исходную версию, если планируется замена существующего файла.
  3. Передайте безвредный тестовый файл в согласованный каталог.
  4. Сверьте размер, содержимое и доступность нужному приложению.
  5. Удалите только собственный тестовый файл штатным способом после приёмки.
  6. Зафиксируйте результат без ключей и паролей.

Для развёртывания нескольких связанных файлов нужен отдельный план согласованности: частичная передача может смешать версии кода. SFTP не переносит базу, cron и настройки панели. Перенос WordPress должен учитывать файлы, данные и окружение, а не завершаться сообщением клиента «очередь пуста».

Чего избегать

Не запускайте команды удаления или смены прав из непонятного руководства. Прежде чем менять файл, проверьте абсолютный путь и назначение. Рекурсивное исправление всех прав одним числом способно нарушить работу или раскрыть данные.

Не храните архив с конфигурацией в публичном каталоге. Не редактируйте рабочий сайт прямо поверх единственной копии. Для большого переноса проверяйте состав скрытых файлов, базу и согласованность данных отдельно: SFTP не копирует базу автоматически.

Как разбирать отказ соединения и прав

Отказ до аутентификации может относиться к адресу, порту, сети или политике сервера. Отказ ключа — к пользователю, формату, разрешённым ключам или способу аутентификации. Ошибка записи после входа — к пути, правам, квоте или модели ограничений. Это разные стадии; смена пароля не исправляет неверный каталог, а chmod не исправляет неподтверждённый сервер.

Передайте администратору время, стадию и точный текст ошибки без закрытого ключа. Подробный журнал клиента может содержать внутренние имена и пути; обезличьте ненужное. Не включайте agent forwarding и дополнительные пробросы ради обхода отказа, если они не требуются утверждённой архитектурой. Не отключайте проверку host key для устранения предупреждения.

Отзыв, замена устройства и аварийный порядок

При завершении работ отзовите конкретный публичный ключ или отдельную учётную запись по модели услуги. Проверьте, что старый способ больше не даёт доступ, а нужные рабочие процессы продолжаются. Удаление локального файла ключа не отзывает опубликованное серверное разрешение. Аналогично удаление WordPress-пользователя не отключает SSH.

При потере устройства сохраните владельцу независимый доступ, отзовите затронутые разрешения и проверьте другие системы, где применялся ключ. Если ключ использовался несколькими людьми, адресный отзыв невозможен — это причина заранее разделять доступы. Замена должна завершаться новым проверенным соединением и актуализацией реестра, а не только генерацией нового файла.

FAQ и результат

SFTP и FTPS — одно и то же?

Нет. Это разные протоколы. Режим клиента должен соответствовать предоставленной услуге.

Какой ключ отправлять администратору?

Только предназначенный публичный ключ по согласованному каналу. Закрытый ключ остаётся у его владельца.

Можно ли автоматически принять сменившийся host key?

Сначала подтвердите смену через независимый доверенный канал. Неожиданное предупреждение нельзя считать формальностью.

Вход работает — значит права правильные?

Нет. Нужно проверить нужный каталог, разрешённые действия и отсутствие лишнего доступа в рамках согласованного теста.

Приёмка доступа включает известный сервер, отдельную запись, защищённый секрет, проверенную область и рабочий отзыв. Доступ должен соответствовать задаче, а перенос данных — иметь собственную проверку и возврат.

Источники и дата

Редакционная переработка: 26.10.2026. Источники относятся к своим версиям продуктов; параметры конкретного проекта необходимо подтвердить отдельно.

↑