SFTP з chroot залежно від відкритого ключа підключення користувача


9

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

У мене була така ідея: кожен клієнт підключається через відкритий ключ auth до backup@backupserver.local. У резервній копії користувача є спеціальний файл з дозволеними ключами, як-от так:

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=...не працює. Файл дозволених_кейсів OpenSSH, схоже, не має еквівалента для ChrootDirectory (який працює в / etc / ssh / sshd_config, або глобально, або в блоці Match User).

Чи є досить простий спосіб виконати те, що я хочу, використовуючи OpenSSH? Може, використовувати command=...директиву розумно? Крім того, чи є інші SFTP-сервери, які можуть робити те, що я хочу?

EDIT : Щоб зробити більш зрозумілим, чого я хочу досягти: я хочу, щоб кілька клієнтів могли зберігати файли на моєму сервері. Кожен клієнт не повинен бачити файли інших клієнтів. І я не хочу засмічувати свій сервер десятками облікових записів користувачів, тому я хотів би легко керувати рішенням, щоб клієнти могли ділитися обліковим записом користувача та все ще не мати доступу до файлів інших.

Відповіді:


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 (Diffie-Hellman).

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

Налаштуйте будь-якого клієнта SFTP. Я використовував FileZilla

Налаштування сервера FileZilla SFTP

Якщо ви запускаєте 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

Примітка: файл повинен містити новий рядок у підсумку! Це важливо.


Дякую за детальну відповідь. Однак я не бачу, як це допомогло б мені досягти моєї основної мети - використовувати лише один обліковий запис користувача для багатьох клієнтів, які не повинні бачити файли інших людей. (І бути легко керованим сценарієм.) Читаючи ще раз своє первісне запитання, я визнаю, що, можливо, це було не зовсім очевидно, чого я хотів досягти. Вибачте за це.
Xykon42

Я оновив відповідь
ALex_hha

1
Гаразд, з невеликою зміною, це насправді прекрасно працює, дякую! Щоб переконатися, що користувачі не можуть отримати доступ до файлів інших користувачів, відгадавши своє ім’я користувача (або затопивши мій сервер, зловживавши функцією CreateHome), файл санкціонований_кіс повинен бути певним для користувача, як-от /foo/authorized_keys.d/%u.
Xykon42

6

chroot=...не працює.

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

Якщо ви покладете chroot command=, ви не зможете користуватися internal-sftp, оскільки це підміна внутрішнього виклику функції всередині sshd.

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

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

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


0

Тим часом я придумав ще одне просте рішення, яке також добре працює, принаймні в моєму випадку використання:

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

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

Разом із командою резервного копіювання сервер повідомляє клієнту ім'я папки, в яку він повинен розміщувати свої файли. Імена папок - це 64-байтні випадкові рядки, які практично не використовуються, тому кожен клієнт може реально отримати доступ лише до власної папки, навіть якщо інші "десь там у темряві".

режим d - x - x-- у темній папці гарантує, що кожен клієнт може входити в папку (і папки нижче), але не може перераховувати її вміст або створювати нові записи.

Підпапки створюються за допомогою сервера резервного копіювання, а з'єднання між клієнтом та папкою зберігається (серед іншого) у sqlite db.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.