SFTP с chroot в зависимости от открытого ключа подключающегося пользователя

9

Я хочу создать сервер (на котором запущен Debian или FreeBSD), который получает резервные копии от разных клиентов через sshfs. Каждый клиент должен иметь возможность читать и записывать свои собственные данные резервного копирования, но не данные других клиентов.

У меня была следующая идея: каждый клиент подключается через открытый ключ аутентификации к backup@backupserver.local. В резервной копии пользователя есть специальный файл author_keys, например:

command="internal-sftp" chroot="/backup/client-1/data" ssh-rsa (key1)
command="internal-sftp" chroot="/backup/client-2/data" ssh-rsa (key2)
command="internal-sftp" chroot="/backup/client-3/data" ssh-rsa (key3)
etc...

Преимущество этого состоит в том, что мне не нужно было бы использовать отдельного пользователя для каждого клиента, и я мог бы легко сгенерировать файл авторизованный_кейс со скриптом.

Есть только одна проблема: chroot=...не работает. Файл author_keys в OpenSSH, похоже, не имеет эквивалента для ChrootDirectory (который работает в / etc / ssh / sshd_config, либо глобально, либо в блоке Match User).

Есть ли достаточно простой способ добиться того, чего я хочу, используя OpenSSH? Может быть, используя command=...директиву умным способом? Или есть ли другие SFTP-серверы, которые могут делать то, что я хочу?

РЕДАКТИРОВАТЬ : Чтобы было яснее, чего я хочу достичь: я хочу, чтобы несколько клиентов могли хранить файлы на моем сервере. Каждый клиент не должен видеть файлы других клиентов. И я не хочу засорять свой сервер десятками учетных записей пользователей, поэтому я бы хотел, чтобы клиенты могли легко управлять учетной записью пользователя и при этом не иметь доступа к файлам друг друга.

Xykon42
источник

Ответы:

5

Или есть ли другие SFTP-серверы, которые могут делать то, что я хочу?

да, вы можете использовать proftpd

Подготовьте пользовательскую среду. С ProFTPD нет необходимости предоставлять пользователю действительную оболочку.

# useradd -m -d /vhosts/backup/user1/ -s /sbin/nologin user1
# passwd --lock user1
Locking password for user user1.
passwd: Success

# mkdir /vhosts/backup/user1/.sftp/
# touch /vhosts/backup/user1/.sftp/authorized_keys

# chown -R user1:user1 /vhosts/backup/user1/
# chmod -R 700 /vhosts/backup/user1/

Чтобы использовать открытые ключи OpenSSH в SFTPAuthorizedUserKeys, необходимо преобразовать их в формат RFC4716. Вы можете сделать это с помощью инструмента ssh-keygen:

# ssh-keygen -e -f user1.public.key > /vhosts/backup/user1/.sftp/authorized_keys

Настройка ProFTPD

ServerName "ProFTPD Default Installation"
ServerType standalone
DefaultServer off

LoadModule mod_tls.c
LoadModule mod_sftp.c
LoadModule mod_rewrite.c

TLSProtocol TLSv1 TLSv1.1 TLSv1.2

# Disable default ftp server
Port 0

UseReverseDNS off
IdentLookups off

# Umask 022 is a good standard umask to prevent new dirs and files
# from being group and world writable.
Umask 022

# PersistentPasswd causes problems with NIS/LDAP.
PersistentPasswd off

MaxInstances 30

# Set the user and group under which the server will run.
User nobody
Group nobody

# Normally, we want files to be overwriteable.
AllowOverwrite                  on

TimesGMT off
SetEnv TZ :/etc/localtime

<VirtualHost sftp.example.net>
    ServerName "SFTP: Backup server."
    DefaultRoot ~
    Umask 002
    Port 2121

    RootRevoke on

    SFTPEngine on
    SFTPLog /var/log/proftpd/sftp.log

    SFTPHostKey /etc/ssh/ssh_host_rsa_key
    SFTPHostKey /etc/ssh/ssh_host_dsa_key
    SFTPDHParamFile /etc/pki/proftpd/dhparam_2048.pem
    SFTPAuthorizedUserKeys file:~/.sftp/authorized_keys

    SFTPCompression delayed
    SFTPAuthMethods publickey
</VirtualHost>

<Global>
    RequireValidShell off
    AllowOverwrite yes

    DenyFilter \*.*/

    <Limit SITE_CHMOD>
        DenyAll
    </Limit>
</Global>

LogFormat default "%h %l %u %t \"%r\" %s %b"
LogFormat auth    "%v [%P] %h %t \"%r\" %s"
ExtendedLog /var/log/proftpd/access.log read,write

Создать параметры группы DH (Диффи-Хеллмана).

# openssl dhparam -out /etc/pki/proftpd/dhparam_2048.pem 2048

Настройте любой SFTP-клиент. Я использовал FileZilla

Настройки SFTP-сервера FileZilla

Если вы запускаете ProFPTD в режиме отладки

# proftpd -n -d 3 

В консоли вы увидите что-то вроде следующего

2016-02-21 22:12:48,275 sftp.example.net proftpd[50511]: using PCRE 7.8 2008-09-05
2016-02-21 22:12:48,279 sftp.example.net proftpd[50511]: mod_sftp/0.9.9: using OpenSSL 1.0.1e-fips 11 Feb 2013
2016-02-21 22:12:48,462 sftp.example.net proftpd[50511] sftp.example.net: set core resource limits for daemon
2016-02-21 22:12:48,462 sftp.example.net proftpd[50511] sftp.example.net: ProFTPD 1.3.5a (maint) (built Sun Feb 21 2016 21:22:00 UTC) standalone mode STARTUP
2016-02-21 22:12:59,780 sftp.example.net proftpd[50512] sftp.example.net (192.168.1.2[192.168.1.2]): mod_cap/1.1: adding CAP_SETUID and CAP_SETGID capabilities
2016-02-21 22:12:59,780 sftp.example.net proftpd[50512] sftp.example.net (192.168.1.2[192.168.1.2]): SSH2 session opened.
2016-02-21 22:12:59,863 sftp.example.net proftpd[50512] sftp.example.net (192.168.1.2[192.168.1.2]): Preparing to chroot to directory '/vhosts/backup/user1'
2016-02-21 22:12:59,863 sftp.example.net proftpd[50512] sftp.example.net (192.168.1.2[192.168.1.2]): Environment successfully chroot()ed
2016-02-21 22:12:59,863 sftp.example.net proftpd[50512] sftp.example.net (192.168.1.2[192.168.1.2]): USER user1: Login successful

И следующие строки в /var/log/sftp.log

2016-02-21 22:12:48,735 mod_sftp/0.9.9[50309]: sending acceptable userauth methods: publickey
2016-02-21 22:12:48,735 mod_sftp/0.9.9[50309]: public key MD5 fingerprint: c2:2f:a3:93:59:5d:e4:38:99:4b:fd:b1:6e:fc:54:6c
2016-02-21 22:12:48,735 mod_sftp/0.9.9[50309]: sending publickey OK
2016-02-21 22:12:59,789 mod_sftp/0.9.9[50309]: public key MD5 fingerprint: c2:2f:a3:93:59:5d:e4:38:99:4b:fd:b1:6e:fc:54:6c
2016-02-21 22:12:59,790 mod_sftp/0.9.9[50309]: sending userauth success
2016-02-21 22:12:59,790 mod_sftp/0.9.9[50309]: user 'user1' authenticated via 'publickey' method

PS

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

SFTPAuthorizedUserKeys file:/etc/sftp/authorized_keys/%u

Я хочу, чтобы несколько клиентов могли хранить файлы на моем сервере. Каждый клиент не должен видеть файлы других клиентов. И я не хочу засорять свой сервер десятками учетных записей пользователей, поэтому я бы хотел, чтобы клиенты могли легко управлять учетной записью пользователя и при этом не иметь доступа к файлам друг друга.

с ProFTPD это тоже возможно. Вам просто нужно немного изменить мою первоначальную конфигурацию

<VirtualHost sftp.example.net>
    ...   
    SFTPAuthorizedUserKeys file:/etc/proftpd/sftp_authorized_keys
    AuthUserFile /etc/proftpd/sftp_users.passwd

    CreateHome on 0700 dirmode 0700 uid 99 gid 99

    RewriteHome on
    RewriteEngine on
    RewriteLog /var/log/proftpd/rewrite.log
    RewriteCondition %m REWRITE_HOME
    RewriteRule (.*) /vhosts/backup/%u
</VirtualHost>

И создать одну виртуальную учетную запись

# ftpasswd --passwd --file /etc/proftpd/sftp_users.passwd --sha512 --gid 99 --uid 99 --shell /sbin/nologin --name user1 --home /vhosts/backup

Это все. Для каждой дополнительной учетной записи все, что вам нужно, это добавить его открытый ключ в / etc / proftpd / sftp_authorized_keys

Примечание: файл должен содержать новую строку в конце! Это важно.

ALex_hha
источник
Спасибо за ваш подробный ответ. Тем не менее, я не понимаю, как это помогло бы мне достичь моей главной цели - использовать только одну учетную запись пользователя для многих клиентов, которые не должны видеть файлы друг друга. (И быть легко управляемым с помощью сценария.) Читая мой оригинальный вопрос снова, я признаю, что, возможно, было не совсем очевидно, чего я хотел достичь. Простите за это.
Xykon42
Я обновил ответ
ALex_hha
1
Хорошо, с небольшим изменением, это на самом деле работает хорошо, спасибо! Чтобы убедиться, что пользователи не могут получить доступ к файлам других пользователей, угадав их имя пользователя (или затопить мой сервер, неправильно использовав функцию CreateHome), файл авторизованные_книги должны быть привязаны к конкретному пользователю, например /foo/authorized_keys.d/%u.
Xykon42
6

chroot=...не работает.

Нет, на странице руководства нет ничего подобного sshd, описывающего формат authorized_keysфайла.

Если вы введете chroot command=, вы не сможете использовать его internal-sftp, потому что это замена внутреннего вызова функции внутри sshd.

Рекомендованным способом является настройка большего количества пользователей, если вам нужно разделение. Вы также можете использовать аргументы internal-sftp, если вам не нужно строгое разделение (например, просто разные рабочие каталоги), например,

command="internal-sftp -d /backup/client-1/data" ssh-rsa (key1)

Также возможно ограничить количество запросов, используя -Pопцию, как на странице руководства для sftp-server.

Jakuje
источник
0

Между тем, я нашел другое простое решение, которое тоже отлично работает, по крайней мере, в моем случае:

Каждый клиент подключается к серверу с той же учетной записью пользователя и, возможно, даже с тем же ключом (не имеет значения). OpenSSH поддерживает каталог, имеющий следующую структуру:

d--x--x---   dark-folder
drwxr-x---   |- verylongrandomfoldername1
drwxr-x---   |- verylongrandomfoldername2
drwxr-x---   `- ...

Вместе с командой резервного копирования сервер сообщает клиенту имя папки, в которую он должен поместить свои файлы. Имена папок - это 64-байтовые случайные строки, которые практически невозможно угадать, поэтому каждый клиент может действительно получить доступ только к своей собственной папке, даже если остальные находятся «где-то в темноте».

Режим d - x - x-- на dark-folder гарантирует, что каждый клиент может войти в папку (и папки ниже), но не может перечислить ее содержимое или создать какие-либо новые записи.

Подпапки создаются процессом сервера резервного копирования, и соединение между клиентом и папкой сохраняется (среди прочего) в базе данных sqlite.

Xykon42
источник