Устранение распространенных ошибок SSH 'Permission Denied' и проблем с подключением

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

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

Понимание процесса аутентификации SSH

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

Аутентификация по открытому ключу: Клиент предоставляет открытый ключ, и сервер проверяет, действителен ли соответствующий закрытый ключ и совпадает ли он с авторизованным ключом (файл authorized_keys).
Аутентификация по паролю: Если аутентификация по ключу не удалась или отключена, сервер запрашивает пароль.

Когда вы получаете Permission denied, это почти всегда означает, что сервер отклонил ваши учетные данные на шаге 1 или 2.

Диагностика проблем с подключением: Мощь подробного режима

Самым эффективным инструментом для диагностики проблем SSH является запуск клиента в подробном режиме. Добавление флагов -v, -vv или -vvv позволяет клиенту выводить подробную отладочную информацию о процессе согласования.

Использование флагов подробного режима

Используйте следующую структуру команды:

ssh -vvv user@remote_host

Что искать в выводе:

Обмен ключами: Ищите строки, указывающие, какие методы аутентификации клиент пытался использовать (например, Offering RSA key: /path/to/id_rsa).
Ответ сервера: Обратите пристальное внимание на сообщения сервера об отказе. Если вывод показывает, что сервер проверяет ключи, но не находит совпадений, проблема, вероятно, связана с конфигурацией ключей или правами доступа на стороне сервера.
Запрос пароля: Если вывод пропускает проверку ключей и сразу запрашивает пароль, аутентификация по ключу может быть отключена на сервере.

Устранение ошибки `Permission denied (publickey)`

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

1. Проверка прав доступа к файлу ключа (на стороне клиента)

В целях безопасности SSH-клиенты очень строго относятся к правам доступа к файлу вашего закрытого ключа (например, ~/.ssh/id_rsa). Если эти файлы слишком открыты, клиент откажется их использовать.

Действенное решение (клиент): Убедитесь, что ваш закрытый ключ доступен для чтения только вами.

chmod 600 ~/.ssh/id_rsa

2. Проверка существования ключа и его правильного использования

Убедитесь, что вы подключаетесь с правильным файлом идентификации, особенно если вы используете нестандартные ключи или несколько пар ключей.

Действенное решение (клиент): Укажите правильный закрытый ключ, используя флаг -i.

ssh -i /path/to/your/specific_private_key user@remote_host

3. Права доступа и владение на стороне сервера

Это наиболее частая причина сбоев. SSH применяет строгие права доступа к каталогам и файлам на сервере для пользователя, под которым вы пытаетесь войти.

Путь на сервере	Требуемые права доступа	Владелец
Каталог `~/.ssh`	`700` (rwx------)	Пользователь
Файл `~/.ssh/authorized_keys`	`600` (rw-------)	Пользователь

Действенное решение (сервер): Войдите через консоль или с использованием аутентификации по паролю (если включена) и выполните эти команды:

# Установка прав доступа для каталога
chmod 700 ~/.ssh

# Установка прав доступа для authorized_keys
chmod 600 ~/.ssh/authorized_keys

# Проверка владения (замените 'myuser' на фактическое имя пользователя)
chown -R myuser:myuser ~/.ssh

Внимание: Если права доступа к домашнему каталогу пользователя (~/) слишком широки (например, доступны для записи группой или другими), SSH также может завершиться сбоем по соображениям безопасности. Стремитесь к 755 или более строгим правам для ~/, если проблемы сохраняются.

4. Подтвердите, что ключ действительно добавлен

Убедитесь, что строка открытого ключа на клиенте точно соответствует тому, что вставлено в файл ~/.ssh/authorized_keys на сервере. Отсутствующий символ или пробел в конце вызовут сбой аутентификации.

Совет: При добавлении ключа используйте ssh-copy-id, если он доступен, так как он автоматически обрабатывает права доступа и форматирование:

ssh-copy-id user@remote_host

Устранение проблем с файлом конфигурации (`sshd_config`)

Если ключи и права доступа верны, проблема часто кроется в файле конфигурации демона SSH, который обычно находится по адресу /etc/ssh/sshd_config на сервере.

1. Проверка методов аутентификации

Убедитесь, что аутентификация по открытому ключу явно разрешена.

Проверка конфигурации: Найдите следующие строки и убедитесь, что они раскомментированы (#) и установлены правильно:

PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

2. Состояние аутентификации по паролю

Если вы временно используете вход по паролю, убедитесь, что он включен. Если установлено значение no, вы должны использовать ключи.

PasswordAuthentication yes

3. PermitRootLogin

Если вы пытаетесь войти как root, убедитесь, что это разрешено. Лучшей практикой обычно является вход под стандартным пользователем и использование sudo, но для устранения неполадок вы можете проверить эту настройку:

PermitRootLogin yes

Важный шаг: После любых изменений в /etc/ssh/sshd_config вы должны перезапустить службу SSH, чтобы изменения вступили в силу:
bash sudo systemctl restart sshd # Или service ssh restart

Другие распространенные ошибки подключения

Хотя проблемы с ключами являются основными, другие ошибки также могут блокировать доступ:

А. Истекло время ожидания соединения

Обычно это означает, что клиент вообще не смог связаться с сервером, что указывает на проблему с сетью, а не с аутентификацией.

Возможные причины:
* Сервер не работает или недоступен.
* Брандмауэр (локальный или сетевой) блокирует соединение по порту 22 (или пользовательскому порту SSH).
* Неправильный IP-адрес или имя хоста.

Устранение неполадок: Используйте ping для проверки базового подключения, а telnet или nc (netcat) — для проверки, открыт ли порт:

# Проверка доступности порта 22
telnet remote_host 22

Б. Нет маршрута к хосту

Подобно тайм-ауту, это проблема сетевой инфраструктуры. Клиент не может найти путь к IP-адресу сервера. Проверьте таблицы маршрутизации, статус VPN или убедитесь, что на удаленном сервере активен действительный сетевой интерфейс.

В. Сервер отклонил наш ключ

Если подробный вывод показывает, что сервер активно отклоняет ключи, но вы проверили файл authorized_keys, проверьте контексты безопасности SELinux или AppArmor на сервере. Эти модули безопасности могут переопределять права доступа к файлам и блокировать доступ SSH, если контексты неверны.

Сводка лучших практик

Всегда используйте подробный режим (-vvv) для диагностики.
Безопасность ключей клиента: Убедитесь, что для закрытых ключей установлены права 600 (chmod 600).
Целостность файлов сервера: Убедитесь, что для ~/.ssh установлены права 700, а для authorized_keys — 600.
Перезапуск демона: Всегда перезапускайте sshd после изменения /etc/ssh/sshd_config.
Используйте ssh-copy-id при любой возможности для автоматизации развертывания ключей.