Каковы причины, по которым я не могу установить подключение к серверу через SSH?

У меня возникли проблемы с подключением к серверу по SSH ключу. Сообщение об ошибке: "Server refused our key" (Сервер отказался от нашего ключа). 

1. Я создал два ключа, приватный и публичный, с помощью PuTTYgen, и скопировал содержимое публичного ключа в файл на сервере в ~/.ssh/authorized_keys. 
2. В настройках PuTTY в разделе ssh-auth выбрал приватный ключ, который находится на моем ПК. 
3. Когда я пытаюсь выполнить команду ssh пользователь@ip_адрес на сервере, появляется сообщение: "Server refused our key". 

Установленные права на директорию и файл следующие: 700 для ~/.ssh и 600 для ~/.ssh/authorized_keys. 

Не могу понять, в чем заключается ошибка. Можете, пожалуйста, помочь?
  • 9 февраля 2025 г. 16:24
Ответы на вопрос 2
Ошибка "Server refused our key" при подключении по SSH может возникать по нескольким причинам. Давайте рассмотрим возможные проблемы и способы их решения:

1. **Правильность ключей**: Убедитесь, что вы правильно скопировали публичный ключ на сервер. Иногда копирование напрямую может привести к дополнительным пробелам или символам. Используйте `cat` или `nano` на сервере, чтобы убедиться, что содержимое в файле `~/.ssh/authorized_keys` соответствует вашему публичному ключу.

2. **Проблемы с форматом ключев**: PuTTYgen генерирует ключи в формате, совместимом с PuTTY. Если вы использовали PuTTY для генерации ключа, убедитесь, что вы используете корректный формат ключа при подключении. Попробуйте экспортировать ключи в OpenSSH-формате через PuTTYgen, если это возможно.

3. **Права доступа**: Вы правильно установили права на директорию и файл, но стоит убедиться, что родительская директория (например, домашняя директория пользователя) имеет правильные права. Для пользователя они должны быть установленными на 755 или 700.

4. **SELinux или другие политики безопасности**: Если на вашем сервере включен SELinux, то он также может блокировать доступ. Вы можете временно отключить его или изменить политику, чтобы проверить, не в этом ли дело. Для временного отключения используйте команду `setenforce 0`, а после проверки можете вернуть обратно командой `setenforce 1`.

5. **SSH демоны и конфигурация**: Проверьте, правильно ли настроен SSH на сервере. Откройте файл конфигурации сервера SSH (`/etc/ssh/sshd_config`) и убедитесь, что следующие параметры установлены:
   ```
   PubkeyAuthentication yes
   AuthorizedKeysFile .ssh/authorized_keys
   ```
   После изменения конфигурации не забудьте перезапустить SSH-демон:
   ```
   sudo systemctl restart sshd
   ```

6. **Логи сервера**: Чтобы получить больше информации об ошибке, посмотрите логи SSH на сервере. Обычно они находятся в файле `/var/log/auth.log` или `/var/log/secure`. Логи могут дать подсказки о том, почему ключ не принимается.

7. **Версия SSH и конфликты**: Убедитесь, что на вашем клиенте и сервере используются совместимые версии SSH и библиотеки. Иногда свежие версии могут вносить изменения, которые могут повлиять на аутентификацию.

Если ни одно из предложенных решений не помогает, попробуйте создать новые ключи и протестировать их, следуя тем же шагам, чтобы исключить возможные ошибки в текущих ключах.
На сервере нужно еще разрешить авторизацию по ключу 
PubkeyAuthentication yes
если используется root то еще и
PermitRootLogin yes
Удостоверься что путь до файла не сменили
AuthorizedKeysFile .ssh/authorized_keys
Проверь что НЕТ чего то типа
AuthorizedKeysFile none

Ну и что бы уж точно понять что не так, включи лог
LogLevel DEBUG3
и перезапусти сервер
sudo systemctl restart sshd
логи тут /var/log/auth.log
Похожие вопросы