SFTP dengan chroot tergantung pada kunci publik untuk menghubungkan pengguna


9

Saya ingin membangun server (menjalankan Debian atau FreeBSD) yang menerima cadangan dari klien yang berbeda melalui sshfs. Setiap klien harus dapat membaca dan menulis data cadangannya sendiri, tetapi bukan data dari klien lain mana pun.

Saya punya ide berikut: setiap klien terhubung melalui kunci publik auth ke backup@backupserver.local. Cadangan pengguna memiliki file otor_keys khusus, seperti ini:

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...

Keuntungan dari hal ini adalah bahwa saya tidak perlu menggunakan pengguna terpisah untuk setiap klien, dan saya dapat dengan mudah membuat otomatis file otor_keys dengan skrip.

Hanya ada satu masalah: chroot=...tidak berfungsi. File otorisasi OpenSSH tampaknya tidak memiliki padanan untuk ChrootDirectory (yang berfungsi di / etc / ssh / sshd_config, baik secara global atau dalam blok Pengguna Pencocokan).

Apakah ada cara yang cukup sederhana untuk mencapai apa yang saya inginkan menggunakan OpenSSH? Mungkin menggunakan command=...arahan dengan cara yang cerdas? Atau, apakah ada server SFTP lain yang dapat melakukan apa yang saya inginkan?

EDIT : Untuk membuatnya lebih jelas apa yang ingin saya capai: Saya ingin beberapa klien dapat menyimpan file di server saya. Setiap klien seharusnya tidak dapat melihat file klien lain. Dan saya tidak ingin mengotori server saya dengan puluhan akun pengguna, jadi saya ingin solusi yang mudah dikelola bagi klien untuk berbagi akun pengguna dan masih tidak memiliki akses ke file satu sama lain.

Jawaban:


5

Atau, apakah ada server SFTP lain yang dapat melakukan apa yang saya inginkan?

ya, Anda bisa menggunakan proftpd

Siapkan lingkungan pengguna. Dengan ProFTPD tidak perlu memberikan shell yang valid kepada pengguna.

# 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/

Untuk menggunakan kunci publik OpenSSH dalam SFTPAuthorizedUserKeys, Anda harus mengubahnya menjadi format RFC4716. Anda dapat melakukan ini dengan alat ssh-keygen:

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

Setup 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

Buat parameter grup DH (Diffie-Hellman).

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

Konfigurasikan klien SFTP apa pun. Saya telah menggunakan FileZilla

Pengaturan server FileZilla SFTP

Jika Anda menjalankan ProFPTD dalam mode debug

# proftpd -n -d 3 

Di konsol Anda akan melihat sesuatu seperti berikut ini

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

Dan baris berikut di /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

Jalur yang dikonfigurasi untuk file yang berisi kunci resmi ( SFTPAuthorizedUserKeys ) dapat menggunakan variabel % u , yang akan diinterpolasi dengan nama pengguna yang diautentikasi. Fitur ini mendukung memiliki file per-pengguna dari kunci yang diotorisasi yang berada di lokasi pusat, daripada mengharuskan (atau mengizinkan) pengguna untuk mengelola kunci resmi mereka sendiri. Sebagai contoh:

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

Saya ingin beberapa klien dapat menyimpan file di server saya. Setiap klien seharusnya tidak dapat melihat file klien lain. Dan saya tidak ingin mengotori server saya dengan puluhan akun pengguna, jadi saya ingin solusi yang mudah dikelola bagi klien untuk berbagi akun pengguna dan masih tidak memiliki akses ke file satu sama lain.

dengan ProFTPD itu mungkin juga. Anda hanya perlu sedikit memodifikasi konfigurasi awal saya

<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>

Dan buat satu akun virtual

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

Itu saja. Untuk setiap akun tambahan, Anda hanya perlu menambahkan kunci publiknya ke / etc / proftpd / sftp_authorized_keys

Catatan: file harus mengandung baris baru pada akhirnya! Ini penting.


Terima kasih atas jawaban Anda. Namun, saya tidak melihat bagaimana ini akan membantu saya mencapai tujuan utama saya hanya menggunakan satu akun pengguna untuk banyak klien yang seharusnya tidak dapat melihat file satu sama lain. (Dan mudah dikelola dengan skrip.) Membaca pertanyaan asli saya lagi, saya akui bahwa mungkin tidak sepenuhnya jelas apa yang ingin saya capai. Maaf untuk itu.
Xykon42

Saya telah memperbarui jawabannya
ALex_hha

1
Oke, dengan perubahan kecil, ini benar-benar berfungsi dengan baik, terima kasih! Untuk memastikan pengguna tidak dapat mengakses file pengguna lain dengan menebak nama pengguna mereka (atau membanjiri server saya dengan menyalahgunakan fungsi CreateHome), file berwenang_kunci harus spesifik untuk pengguna, seperti /foo/authorized_keys.d/%u.
Xykon42

6

yang chroot=...tidak bekerja.

Tidak, tidak ada yang seperti itu di halaman manual untuk sshd, menggambarkan format authorized_keysfile.

Jika Anda akan memasukkan chroot ke dalam command=, Anda tidak akan dapat menggunakan internal-sftp, karena itu adalah pengganti panggilan fungsi internal sshd.

Cara yang disarankan adalah mengatur lebih banyak pengguna, jika Anda membutuhkan pemisahan. Anda mungkin juga menggunakan argumen untuk internal-sftp, jika Anda tidak memerlukan pemisahan yang ketat (untuk exaxmple hanya direktori kerja yang berbeda), seperti

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

Ada juga kemungkinan untuk membatasi jumlah permintaan menggunakan -Popsi seperti pada halaman manual untuk sftp-server.


0

Sementara itu, saya datang dengan solusi sederhana lain yang berfungsi dengan baik juga, setidaknya dalam kasus penggunaan saya:

Setiap klien terhubung ke server dengan akun pengguna yang sama dan bahkan mungkin kunci yang sama (tidak masalah). OpenSSH chroots ke dalam direktori yang memiliki struktur berikut:

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

Bersama dengan perintah cadangan, server memberi tahu klien nama folder tempat file itu dimasukkan. Nama folder adalah string acak 64-byte yang hampir tidak dapat dilewati, sehingga setiap klien hanya dapat benar-benar mengakses foldernya sendiri, meskipun yang lain "di suatu tempat di luar sana dalam gelap".

mode d - x - x-- pada dark-folder memastikan bahwa setiap klien dapat memasukkan folder (dan folder di bawah), tetapi tidak dapat membuat daftar isinya atau membuat entri baru.

Subfolder dibuat oleh proses server cadangan dan koneksi antara klien dan folder disimpan (antara lain) di db sqlite.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.