Посещая наш сайт, вы соглашаетесь с нашей политикой конфиденциальности в отношении файлов cookie, статистики отслеживания и т. д.

Главная » Вопросы и ответы » Убунту

SSH / SFTP Доступ запрещен (публичный ключ)

На чтение 6 мин Опубликовано
Содержание
  1. Вопрос или проблема
  2. Ответ или решение
  3. Возможные Причины и Решения
  4. Заключение

Вопрос или проблема

Я добавил следующее в свой sshd_config

Match Group sftponly
ChrootDirectory /srv/sftpfolder
ForceCommand internal-sftp
#AllowTcpForwarding no
PermitTunnel no
X11Forwarding no

Я создал “пользователя” с помощью
useradd -g sftponly user
mkdir -p /home/user/.ssh
А затем создал файл authorized_keys в папке ssh пользователя.

Права доступа к /home/user/.ssh/ составляют 700, а к файлу authorized_keys 600.

Но когда я пробую sftp -P 12345 user@ip-address, я получаю следующее.

sftp -P 12345 -v user@ip-address
OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n  7 Dec 2017
debug1: Чтение конфигурационных данных /home/user/.ssh/config
debug1: /home/user/.ssh/config строка 1: Применение параметров для *
debug1: Чтение конфигурационных данных /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config строка 19: Применение параметров для *
debug1: auto-mux: Попытка подключения к существующему мастеру
debug1: Контрольный сокет "/home/user/.ssh/master-d986de8e7074586561615461cc918c33db0e1d57" не существует
debug1: Подключение к ip-address [185.104.140.216] порт 12345.
debug1: Соединение установлено.
debug1: Файл идентификации /home/user/.ssh/id_rsa тип 0
debug1: key_load_public: Нет такого файла или директории
debug1: Файл идентификации /home/user/.ssh/id_rsa-cert тип -1
debug1: key_load_public: Нет такого файла или директории
debug1: Файл идентификации /home/user/.ssh/id_dsa тип -1
debug1: key_load_public: Нет такого файла или директории
debug1: Файл идентификации /home/user/.ssh/id_dsa-cert тип -1
debug1: key_load_public: Нет такого файла или директории
debug1: Файл идентификации /home/user/.ssh/id_ecdsa тип -1
debug1: key_load_public: Нет такого файла или директории
debug1: Файл идентификации /home/user/.ssh/id_ecdsa-cert тип -1
debug1: key_load_public: Нет такого файла или директории
debug1: Файл идентификации /home/user/.ssh/id_ed25519 тип -1
debug1: key_load_public: Нет такого файла или директории
debug1: Файл идентификации /home/user/.ssh/id_ed25519-cert тип -1
debug1: Локальная версия: SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
debug1: Удаленная версия протокола 2.0, удаленное программное обеспечение версия OpenSSH_7.9p1 Debian-10+deb10u1
debug1: совпадение: OpenSSH_7.9p1 Debian-10+deb10u1 pat OpenSSH* compat 0x04000000
debug1: Аутентификация на ip-address:12345 как 'user'
debug1: SSH2_MSG_KEXINIT отправлено
debug1: SSH2_MSG_KEXINIT получено
debug1: kex: алгоритм: curve25519-sha256
debug1: kex: алгоритм ключа хоста: ecdsa-sha2-nistp256
debug1: kex: шифр сервера->клиенту: [email protected] MAC: <implicit> сжатие: none
debug1: kex: шифр клиенту->серверу: [email protected] MAC: <implicit> сжатие: none
debug1: ожидаем SSH2_MSG_KEX_ECDH_REPLY
debug1: Ключ хоста сервера: ecdsa-sha2-nistp256 SHA256:/Pd8kuuE858qr7V6RZhdMw8u+3xbxp/CZGVtinPfUmU
debug1: Хост '[ip-address]:12345' известен и соответствует ключу хоста ECDSA.
debug1: Ключ найден в /home/user/.ssh/known_hosts:1
debug1: смена ключа после 134217728 блоков
debug1: SSH2_MSG_NEWKEYS отправлено
debug1: ожидаем SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS получено
debug1: смена ключа после 134217728 блоков
debug1: SSH2_MSG_EXT_INFO получено
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT получено
debug1: Аутентификации, которые могут продолжиться: publickey
debug1: Следующий метод аутентификации: publickey
debug1: Предложение открытого ключа: RSA SHA256:66x60sLHiBKnCaV4hjwStZBp3SJczxVw7WhWouQECWQ /home/user/.ssh/id_rsa
debug1: Аутентификации, которые могут продолжиться: publickey
debug1: Попытка закрытого ключа: /home/user/.ssh/id_dsa
debug1: Попытка закрытого ключа: /home/user/.ssh/id_ecdsa
debug1: Попытка закрытого ключа: /home/user/.ssh/id_ed25519
debug1: Больше нет методов аутентификации для попытки.
user@ip-address: Доступ запрещен (publickey).
Соединение закрыто

Не хватает ли мне чего-то?
Вход с правами root работает как ожидается…

Хорошо, я решил это. Оказалось, что я правильно настроил разрешения для файлов authorized_keys и домашнего каталога пользователя. Однако владельцем был root:sftponly.

Ответ или решение

Проблема, с которой вы столкнулись при попытке подключения к серверу SSH/SFTP, заключается в том, что аутентификация через ключи не прошла успешно. Судя по вашему сообщению об ошибке, вы получили сообщение "Permission denied (publickey)", что указывает на проблемы с правами доступа или с конфигурацией пользователя.

Возможные Причины и Решения

  1. Права доступа к файлам и директориям:

    • Вы правильно указали, что права на директорию .ssh должны быть 700, а на файл authorized_keys — 600. Однако важно также, чтобы домашняя директория пользователя имела корректные права. Если у домашней директории пользователя установлены права 755 или более открытые, это также может вызвать проблемы с доступом.
    • Убедитесь, что домашняя директория пользователя (/home/user) имеет права доступа 750 и принадлежит правильному владельцу: 
      chown root:sftponly /home/user
chmod 750 /home/user

  2. Права и Владелец /srv/sftpfolder:

    • Проверьте, что ChrootDirectory указана правильно. Для ChrootDirectory также необходимо установить владельца на root и разрешить доступ только для чтения: 
      chown root:root /srv/sftpfolder
chmod 755 /srv/sftpfolder

  3. Содержимое authorized_keys:

    • Убедитесь, что файл authorized_keys содержит корректный публичный SSH-ключ, созданный для пользователя user. Если ключ не был сгенерирован или скопирован неверно, это также может привести к ошибке аутентификации. Вы можете сгенерировать пару ключей с помощью: 
      ssh-keygen -t rsa -b 2048
    • После генерации убедитесь, что публичный ключ добавлен в файл ~/.ssh/authorized_keys на сервере.

  4. Параметры конфигурации SSH:

    • Проверьте настройки в файле /etc/ssh/sshd_config. Убедитесь, что у вас включена аутентификация по ключам: 
      PubkeyAuthentication yes
    • После внесения изменений не забудьте перезагрузить службу SSH: 
      systemctl restart sshd

  5. Журнал ошибок:

    • Если все вышеперечисленное выглядит правильно, рекомендуется проверить журналы сервера, чтобы найти дополнительные подсказки о проблеме. Журнал ошибок SSH можно найти в /var/log/auth.log или /var/log/secure в зависимости от вашей системы. Посмотрите на последние записи, чтобы идентифицировать причину отказа.

Заключение

Теперь, когда вы исправите права доступа и убедитесь, что все ключи и настройки соответствуют ожидаемым требованиям, вы должны смочь успешно подключиться к серверу SFTP под своим пользователем. Если проблемы сохраняются, проверьте журнал и при необходимости обратитесь к дополнительным ресурсам по SSH/SFTP.

openssh permissions sftp ssh
Оцените материал
Добавить комментарий

Капча загружается...

© 2024 IZ6.RU
*В материалах сайта упоминаются социальные сети Фейсбук / Инстаграм, принадлежащие Meta Platforms Inc., деятельность которой запрещена на территории РФ в части реализации данных социальных сетей на основании осуществления ею экстремистской деятельности