SSH Authentication Failure: как исправить ошибку доступа в Linux

Что означает ошибка аутентификации SSH

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

Permission denied (publickey,password).

или

Authentication failed.

Эта ошибка блокирует подключение на уровне безопасности, даже если сетевые параметры (хост, порт) верны. Проблема может быть как на стороне клиента (неверные ключи/пароль), так и на стороне сервера (неправильные настройки или права).

Причины возникновения

1. Неверное имя пользователя или пароль — вы указали несуществующего пользователя или ошиблись в пароле.
2. Отсутствует или неправильный SSH-ключ — публичный ключ не добавлен в ~/.ssh/authorized_keys на сервере, либо используется не тот приватный ключ.
3. Неправильные права на файлы SSH на сервере — права на ~/.ssh или ~/.ssh/authorized_keys слишком открытые (например, 777), что считается угрозой безопасности.
4. Аутентификация по паролю отключена на сервере — в /etc/ssh/sshd_config стоит PasswordAuthentication no.
5. Публичный ключ имеет неверный формат — например, добавлен в authorized_keys с лишними пробелами или переносами строк.
6. SSH-агент не загрузил ключ — ключ существует, но не добавлен в ssh-agent, и клиент не может его найти.
7. Конфликт ключей — на сервере в authorized_keys несколько ключей, и сервер отвергает предоставленный.

Способы решения

Способ 1: Проверка и корректировка учетных данных

Шаг 1: Убедитесь, что имя пользователя верное. Для локального пользователя john на сервере 192.168.1.10 команда должна быть:

ssh john@192.168.1.10

Шаг 2: Если используете пароль, введите его внимательно. Учтите, что при вводе пароля символы не отображаются (это нормально).

Шаг 3: При использовании SSH-ключей:

• Проверьте, что приватный ключ существует (обычно ~/.ssh/id_rsa или ~/.ssh/id_ed25519).
• Загрузите ключ в ssh-agent:

  eval "$(ssh-agent -s)"
  ssh-add ~/.ssh/id_rsa
  

• Убедитесь, что соответствующий публичный ключ (с расширением .pub) добавлен в ~/.ssh/authorized_keys на сервере. Можно скопировать ключ командой:

  ssh-copy-id -i ~/.ssh/id_rsa.pub user@host
  

Способ 2: Исправление прав доступа на сервере

Неправильные права — самая частая причина. На сервере (если у вас есть доступ) выполните:

# Перейдите в домашнюю директорию целевого пользователя
cd /home/username

# Установите правильные права
chmod 700 .ssh
chmod 600 .ssh/authorized_keys

# Убедитесь, что владелец — целевой пользователь
chown -R username:username .ssh

⚠️ Важно: Если домашняя директория (/home/username) доступна для записи другим пользователям (права 777 или группа write), SSH может отказать в аутентификации. Исправьте права: chmod 755 /home/username (или 750).

Способ 3: Проверка и настройка конфигурации SSH-сервера

На сервере откройте файл конфигурации:

sudo nano /etc/ssh/sshd_config

Убедитесь, что следующие строки раскомментированы (без # в начале) и имеют нужные значения:

# Для аутентификации по паролю
PasswordAuthentication yes

# Для аутентификации по ключам
PubkeyAuthentication yes

# Разрешить вход для конкретного пользователя (опционально)
AllowUsers username

💡 Совет: Если вы настраиваете сервер впервые, временно оставьте оба метода (yes), чтобы протестировать подключение. После успешной настройки ключей можно отключить пароль (PasswordAuthentication no) для безопасности.

Перезапустите службу SSH:

sudo systemctl restart sshd
# Или для старых систем:
# sudo service ssh restart

Способ 4: Явное указание ключа при подключении

Если у вас несколько ключей, SSH может пытаться использовать не тот. Укажите путь к нужному приватному ключу:

ssh -i ~/.ssh/id_ed25519_custom user@host

Также можно создать или отредактировать ~/.ssh/config на клиенте:

Host myserver
    HostName 192.168.1.10
    User username
    IdentityFile ~/.ssh/id_ed25519_custom

После этого достаточно команды ssh myserver.

Способ 5: Анализ логов SSH-сервера

Если предыдущие шаги не помогли, посмотрите логи сервера. Они содержат точную причину отказа.

На большинстве Linux-систем:

sudo tail -f /var/log/auth.log
# Для CentOS/RHEL/Fedora:
# sudo tail -f /var/log/secure

Подключитесь с клиента и наблюдайте за логами в реальном времени. Типичные сообщения:

• Failed publickey for user from 192.168.1.5 port 56789 ssh2: RSA SHA256:... — ключ не принят.
• Failed password for user from 192.168.1.5 port 56789 ssh2 — неверный пароль.
• Authentication refused: bad ownership or modes for directory /home/user — неправильные права.

Профилактика

1. Используйте безопасные права — всегда устанавливайте chmod 700 ~/.ssh и chmod 600 ~/.ssh/authorized_keys на сервере.
2. Отключайте аутентификацию по паролю после настройки ключей — это защитит от брутфорса.
3. Регулярно обновляйте OpenSSH — следите за обновлениями безопасности: sudo apt update && sudo apt upgrade openssh-server (Ubuntu/Debian) или sudo yum update openssh-server (CentOS).
4. Используйте надежные ключи — минимум 3072 бит для RSA или Ed25519.
5. Настройте фаервол — ограничьте доступ к порту 22 только доверенными IP-адресами:

   sudo ufw allow from 192.168.1.0/24 to any port 22
   

6. Мониторьте логи — настройте регулярный просмотр /var/log/auth.log или интеграцию с SIEM-системой.

# Пример проверки конфигурации сервера без перезагрузки
sudo sshd -t
# Если вывод пустой — конфигурация синтаксически верна.