☰

поделиться открытым ключом ssh в конфигурации sftp

tag-icon • tag-icon ssh centos sftp public-key
поделиться открытым ключом ssh в конфигурации sftp

Я настроил SFTP-сервер на CentOS следующим образом:этот документ. Я намерен запретить вход в консоль для новых пользователей ( user1, user2), которые принадлежат к sftpusersгруппе, но по-прежнему могут входить в свои соответствующие sftpпапки.

Также я хочу использовать те же ключи, которые использует пользователь CentOS (который может войти в консоль sftpбез проблем). Для этого я скопировал .sshпапку из пользователя CentOS в user1и user2домашние папки, изменив владельца на пользователей и 700для .sshпапки и 600для authorized_keysфайла.

Тем не менее, я продолжаю получать сообщение Server refused our key. Ключ, используемый пользователем CentOS, является главным ключом на всех серверах, поэтому я хочу повторно использовать этот ключ для новых пользователей.

Как мне добиться такой конфигурации?

ОБНОВЛЯТЬ

После генерации ключей для каждого пользователя оба пользователя могут получить удаленный доступ к серверу с помощью своих закрытых ключей, но когда я активирую следующую конфигурацию в /etc/ssh/sshd_configразрешениях с помощью команды, они отказываются sftp.

Конфигурация SSHD

Match Group sftpusers #Or you could replace Group with User and specify a different configuration for each user
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
ChrootDirectory /path/to/shared_folder/%u # %h the path to upload the files
ForceCommand internal-sftp

Сообщение от shell

packet_write_wait: Connection to IPSERVER port 22: Broken pipe
Couldn't read packet: Connection reset by peer

решение1

Обновление вводит проблему, отличную от исходного вопроса. Похоже, исходная проблема больше не является проблемой. Я занимаюсь обновлением.

Theруководствочитает:

ChrootDirectory
Указывает путь к каталогу chroot(2)после аутентификации. При запуске сеанса sshd(8)проверяет, что все компоненты пути являются каталогами, принадлежащими root, которые не доступны для записи никакому другому пользователю или группе.

Мои тесты показывают, что если это условие не выполняется, то Broken pipeпри попытке входа в систему с помощью sftp.

В вашем случае имя пути /path/to/shared_folder/%u. Примечание %u(после расширения)такжекомпонент; поэтому он должен быть «принадлежащим root и не доступным для записи любым другим пользователем или группой». Вам следует исправить владельца и разрешения. Тогда, очевидно, пользователь не сможет писать в каталог. Какой бы путь вы ни использовали с ChrootDirectory, пользователь не сможет писать в него (если только он не root). Другими словами, пользователь не сможет писать /в chrooted-среде. Чтобы разрешить запись, вам нужен подкаталог. Есть несколько способов справиться с этим.

  • Использование домашних каталогов в общем chroot-каталоге.

    В руководстве также указано:

    После этого chrootрабочий sshd(8)каталог меняется на домашний каталог пользователя.

    Я предполагаю, что домашние каталоги по умолчанию такие /home/user1, как /home/user2и т. д. Это предполагает следующий сценарий:

    1. Настройте сервер на chroot /path/to/shared_folder(нет %u):

      ChrootDirectory /path/to/shared_folder

    2. Скопируйте туда соответствующую структуру каталогов ( /path/to/shared_folder/home/user1и т. д.).

    3. Удовлетворить условию для path, toи shared_folder.
    4. Сделайте права собственности и разрешения homeтакими же, как для обычного /home.
    5. Создайте права собственности и разрешения для каталогов внутри, homeкак для каталогов в /home.

    При такой настройке sftpон будет автоматически помещаться user1после /path/to/shared_folder/home/user1аутентификации, но они будут видеть это как /home/user1из-за chroot.

  • Использование пользовательских каталогов в общем chroot-каталоге.

    С помощью ForceCommand internal-sftpможно указать начальный каталог ( internal-sftpподдерживает тот же набор опций, что иsftp-server). Так:

    ChrootDirectory /path/to/shared_folder
ForceCommand internal-sftp -d /home/%u

    чтобы убедиться, что sftpпользователи будут использовать /path/to/shared_folder/home/…независимо от их формальных домашних каталогов в ОС. Или так:

    ChrootDirectory /path/to/shared_folder
ForceCommand internal-sftp -d /%u

    для упрощения путей и избавления от этого homeв середине. Таким образом, user1они будут видны /user1после входа в систему с помощью sftp. В этом случае shared_folderдолжны напрямую содержать пользовательские папки (не home).

  • Использование по крайней мере одного подкаталога в каталоге chroot, специфичного для пользователя.

    Решения выше позволяют пользователям просматривать каталоги друг друга. Пользователь сможет к chmodсвоим файлам ( sftpподдерживает chmod) предоставлять или запрещать доступ.

    Вы использовали %uс ChrootDirectory, поэтому вы, скорее всего, хотите создать отдельные каталоги chroot. В таком случае сделайте то, что вы сделали:

    ChrootDirectory /path/to/shared_folder/%u

    и установить владельца и разрешения для каждого компонента (включая то, %uво что он расширяется) для удовлетворения условия. Если речь не идет о доступе только для чтения, вам нужен по крайней мере один подкаталог, который будет доступен для записи пользователем. Несколько возможностей:

    • реплицирование пути к домашнему каталогу пользователя, как определено в ОС;
    • форсирование /home/%uс помощью ForceCommand internal-sftp -d /home/%u;
    • форсирование /%uс помощью ForceCommand internal-sftp -d /%u;
    • используя фиксированное имя подкаталога, например ForceCommand internal-sftp -d /files.

    В каждом случае вам необходимо подготовить структуру каталогов внутри /path/to/shared_folder. Например, если вы хотите принудительно выполнить /home/user1, user1соответствующий путь будет:

    /path/to/shared_folder/user1/home/user1

    где path, to, shared_folderи (первый) user1удовлетворяет условию, homeимитирует /homeи (второй) user1доступен для записи пользователем.

Возможны более гибкие подходы. Например, вы можете иметь общий chroot-каталог для user1и user2, но другой для user3.

Директория chroot распространена или нет, лично я бы сделал подкаталоги наименее неожиданным образом, так что любой пользователь окажется в каталоге, который он ожидает. После ввода pwdони sftpдолжны увидеть что-то вроде /home/user1. Я нахожу другие возможности ( /user1, /files) несколько удивительными.

Связанный контент