Устранение распространенных ошибок SSH 'Permission Denied' и проблем с подключением
Освойте SSH-соединения, научившись преодолевать ошибки 'Permission denied'. Это руководство подробно описывает, как использовать подробный режим (`-vvv`) для диагностики сбоев аутентификации, исправлять критические разрешения файлов на стороне сервера (`700`/`600`) для каталогов `.ssh` и проверять необходимые настройки конфигурации сервера в `sshd_config` для надежного удаленного доступа.
Устранение распространенных ошибок SSH 'Permission Denied' и проблем с подключением
Ошибка SSH Permission denied обычно означает, что сервер был доступен, но отказался вас аутентифицировать. Это отличается от Connection timed out, Connection refused или No route to host. Рассматривать все эти ошибки как "SSH не работает" — пустая трата времени, поэтому начните с разделения ошибок аутентификации и сетевых ошибок.
Запустите команду, которая вызывает ошибку, с подробным журналированием:
ssh -vvv user@remote_host
Вы ищете явные подсказки: какое имя пользователя использовал клиент, какие файлы ключей он предложил, принял ли сервер какой-либо ключ и какие методы аутентификации остались. Большинство исправлений ниже основаны на сопоставлении этих подсказок с состоянием сервера.
Понимание процесса аутентификации SSH
Когда вы пытаетесь подключиться, сервер разрешает только те методы аутентификации, которые включены в его конфигурации. Типичный сервер сначала пробует аутентификацию по открытому ключу и может разрешить аутентификацию по паролю после этого, в зависимости от политики:
- Аутентификация по открытому ключу: Клиент представляет открытый ключ, а сервер проверяет, действителен ли соответствующий закрытый ключ и соответствует ли он авторизованному ключу (файл
authorized_keys). - Аутентификация по паролю: Если аутентификация по ключу не удалась или отключена, сервер запрашивает пароль.
Когда вы получаете Permission denied, TCP-соединение установлено. Сервер просто не принял предоставленные вами учетные данные для этого пользователя.
Диагностика проблем с подключением: сила подробного режима
Самый эффективный инструмент для диагностики проблем SSH — запуск клиента в подробном режиме. Добавляя флаги -v, -vv или -vvv, клиент выводит подробную отладочную информацию о процессе согласования.
Использование флагов подробного режима
Используйте следующую структуру команды:
ssh -vvv user@remote_host
На что обратить внимание в выводе:
- Имя пользователя: Ищите
Authenticating to ... as 'user'. Неправильное имя пользователя Linux — одна из самых простых ошибок, которые можно пропустить. - Предложенные ключи: Ищите
Offering public key. Если ожидаемый ключ так и не появился, исправьте конфигурацию клиента. - Ответ сервера: Если за каждым предложенным ключом следует
Authentications that can continue, сервер отклонил эти ключи. - Методы аутентификации: Если
publickeyне указан, сервер может не разрешать аутентификацию по ключу для этой учетной записи или блока хоста.
Решение проблемы 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
Если в вашем агенте загружено много ключей, добавьте IdentitiesOnly=yes для этого теста:
ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_prod 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
Если домашний каталог пользователя доступен для записи группе или другим пользователям, OpenSSH также может отклонить ключ, когда включен StrictModes. Проверьте с помощью:
ls -ld ~ ~/.ssh ~/.ssh/authorized_keys
Для большинства обычных домашних каталогов пользователей 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
Также проверьте блоки Match в нижней части файла. Глобальная настройка может разрешать открытые ключи, в то время как более поздний блок Match User, Match Group или Match Address может отключать их для конкретного тестируемого входа.
2. Статус аутентификации по паролю
Если вы временно полагаетесь на вход по паролю, убедитесь, что он включен. Если он установлен в no, вы обязаны использовать ключи.
PasswordAuthentication yes
3. PermitRootLogin
Если вы пытаетесь войти как root, убедитесь, что это разрешено. Рекомендуется входить как обычный пользователь и использовать sudo, но для устранения неполадок вы можете проверить этот параметр:
PermitRootLogin prohibit-password
Для входа root многие системы по умолчанию разрешают доступ только по ключу или полностью отключают вход root. Предпочтительнее использовать обычного пользователя с sudo. Если вам необходимо изменить настройки демона SSH, проверьте синтаксис перед перезагрузкой:
sudo sshd -t
sudo systemctl reload sshd # В некоторых системах: sudo systemctl reload ssh
Другие распространенные ошибки подключения
Хотя проблемы с ключами являются основными, другие ошибки могут блокировать доступ:
A. Connection Timed Out
Это обычно означает, что клиент вообще не смог связаться с сервером, что указывает на сетевую проблему, а не на проблему аутентификации.
Возможные причины:
- Сервер не работает или недоступен.
- Брандмауэр (локальный или сетевой) блокирует соединение на порту 22 (или пользовательском порту SSH).
- Неправильный IP-адрес или имя хоста.
Используйте ping для базовой проверки доступности и nc для проверки порта SSH:
nc -vz remote_host 22
B. No Route to Host
Аналогично тайм-ауту, это проблема сетевой инфраструктуры. Клиент не может найти путь к IP-адресу сервера. Проверьте таблицы маршрутизации, статус VPN или убедитесь, что на удаленном сервере активен действующий сетевой интерфейс.
C. Server Refused Our Key
Если подробный вывод показывает, что сервер активно отклоняет ключи, но вы проверили файл authorized_keys, проверьте контексты безопасности SELinux или AppArmor на сервере. Эти модули безопасности могут переопределять разрешения файлов и блокировать доступ SSH, если контексты неверны.
Практический порядок действий, который обычно работает
Сначала проверьте имя пользователя. Затем принудительно используйте ожидаемый ключ с помощью ssh -o IdentitiesOnly=yes -i .... Если клиент предлагает правильный ключ, а сервер его отклоняет, проверьте authorized_keys, владельца и разрешения на сервере. Если ключ никогда не предлагается, исправьте локальный ~/.ssh/config, агент или путь к ключу. Если соединение никогда не доходит до аутентификации, переключитесь на устранение сетевых неполадок вместо изменения файлов ключей.