SFTP với chroot tùy thuộc vào khóa chung của người dùng kết nối


9

Tôi muốn xây dựng một máy chủ (chạy Debian hoặc FreeBSD) để nhận các bản sao lưu từ các máy khách khác nhau thông qua sshfs. Mỗi khách hàng sẽ có thể đọc và ghi dữ liệu sao lưu của riêng mình, nhưng không phải là dữ liệu của bất kỳ khách hàng nào khác.

Tôi đã có một ý tưởng sau: mỗi khách hàng kết nối thông qua khóa công khai auth đến backup@backupserver.local. Bản sao lưu người dùng có tệp ủy quyền đặc biệt, như thế này:

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

Ưu điểm của việc này là tôi sẽ không cần sử dụng một người dùng riêng cho mọi khách hàng và tôi có thể dễ dàng tự động tạo tệp ủy quyền bằng một tập lệnh.

Chỉ có một vấn đề: chroot=...không hoạt động. Tệp ủy quyền của OpenSSH dường như không có tương đương với ChrootDirectory (hoạt động trong / etc / ssh / sshd_config, trên toàn cầu hoặc trong khối Người dùng phù hợp).

Có cách nào hợp lý đơn giản để thực hiện những gì tôi muốn bằng OpenSSH không? Có thể sử dụng command=...chỉ thị một cách thông minh? Ngoài ra, có máy chủ SFTP nào khác có thể làm những gì tôi muốn không?

EDIT : Để làm rõ hơn những gì tôi muốn đạt được: Tôi muốn một số khách hàng có thể lưu trữ các tệp trên máy chủ của tôi. Mỗi khách hàng sẽ không thể xem bất kỳ tệp nào của khách hàng khác. Và tôi không muốn xả rác máy chủ của mình với hàng tá tài khoản người dùng, vì vậy tôi muốn một giải pháp dễ quản lý để khách hàng chia sẻ tài khoản người dùng và vẫn không có quyền truy cập vào các tệp của nhau.

Câu trả lời:


5

Ngoài ra, có máy chủ SFTP nào khác có thể làm những gì tôi muốn không?

vâng, bạn có thể sử dụng proftpd

Chuẩn bị môi trường người dùng. Với ProFTPD, không cần phải cung cấp cho người dùng một vỏ hợp lệ.

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

Để sử dụng các khóa công khai OpenSSH trong SFTPAuthorizedUserKeys, bạn phải chuyển đổi chúng sang định dạng RFC4716. Bạn có thể làm điều này với công cụ ssh-keygen:

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

Thiết lập 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

Tạo tham số nhóm DH (Diffie-Hellman).

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

Cấu hình bất kỳ máy khách SFTP nào. Tôi đã sử dụng FileZilla

Cài đặt máy chủ SFZ FileZilla

Nếu bạn chạy ProFPTD ở chế độ gỡ lỗi

# proftpd -n -d 3 

Trong bảng điều khiển, bạn sẽ thấy một cái gì đó như sau

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

Và các dòng theo dõi trong /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

Đường dẫn được định cấu hình cho tệp chứa các khóa được ủy quyền ( SFTPAuthorizedUserKeys ) có thể sử dụng biến % u , sẽ được nội suy với tên của người dùng được xác thực. Tính năng này hỗ trợ có các tệp theo người dùng của các khóa được ủy quyền nằm ở vị trí trung tâm, thay vì yêu cầu (hoặc cho phép) người dùng quản lý các khóa được ủy quyền của riêng họ. Ví dụ:

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

Tôi muốn một số khách hàng có thể lưu trữ các tập tin trên máy chủ của tôi. Mỗi khách hàng sẽ không thể xem bất kỳ tệp nào của khách hàng khác. Và tôi không muốn xả rác máy chủ của mình với hàng tá tài khoản người dùng, vì vậy tôi muốn một giải pháp dễ quản lý để khách hàng chia sẻ tài khoản người dùng và vẫn không có quyền truy cập vào các tệp của nhau.

với ProFTPD cũng có thể. Bạn chỉ cần sửa đổi một chút cấu hình ban đầu của tôi

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

Và tạo một tài khoản ảo

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

Đó là tất cả. Đối với mỗi tài khoản bổ sung, tất cả những gì bạn cần là thêm khóa công khai của anh ấy vào / etc / proftpd / sftp_ trái_keys

Lưu ý: tập tin phải chứa dòng mới cuối cùng! Nó quan trọng.


Cảm ơn bạn đã trả lời của bạn. Tuy nhiên, tôi không thấy cách này sẽ giúp tôi đạt được mục tiêu chính là chỉ sử dụng một tài khoản người dùng cho nhiều khách hàng không thể xem các tệp của nhau. (Và có thể dễ dàng quản lý bằng một kịch bản.) Đọc lại câu hỏi ban đầu của tôi, tôi thừa nhận rằng nó có thể không hoàn toàn rõ ràng những gì tôi muốn đạt được. Xin lỗi vì điều đó.
Xykon42

Tôi đã cập nhật câu trả lời
ALex_hha

1
Được rồi, với một thay đổi nhỏ, điều này thực sự hoạt động tốt, cảm ơn! Để đảm bảo người dùng không thể truy cập các tệp của người dùng khác bằng cách đoán tên người dùng của họ (hoặc làm ngập máy chủ của tôi bằng cách sử dụng sai chức năng CreatHome), tệp ủy quyền cần phải được người dùng cụ thể, như /foo/authorized_keys.d/%u.
Xykon42

6

các chroot=...không hoạt động.

Không, không có gì giống như vậy trong trang hướng dẫn sshd, mô tả định dạng của authorized_keystệp.

Nếu bạn đặt chroot vào command=, bạn sẽ không thể sử dụng internal-sftp, vì đó là sự thay thế của chức năng gọi bên trong sshd.

Cách được đề xuất là thiết lập nhiều người dùng hơn, nếu bạn cần tách. Bạn cũng có thể sử dụng các đối số để internal-sftp, nếu bạn không cần tách biệt nghiêm ngặt (đối với exaxmple chỉ là các thư mục làm việc khác nhau), chẳng hạn như

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

Cũng có thể giới hạn số lượng yêu cầu sử dụng -Ptùy chọn như trong trang thủ công cho sftp-server.


0

Trong khi đó, tôi đã đưa ra một giải pháp đơn giản khác cũng hoạt động tốt, ít nhất là trong trường hợp sử dụng của tôi:

Mọi máy khách kết nối với máy chủ có cùng một tài khoản người dùng và thậm chí có thể cùng một khóa (không thành vấn đề). OpenSSH chroots vào một thư mục có cấu trúc sau:

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

Cùng với lệnh sao lưu, máy chủ sẽ cho khách hàng biết tên thư mục mà nó sẽ đặt các tệp của nó vào. Tên thư mục là các chuỗi ngẫu nhiên 64 byte hầu như không thể truy cập được, vì vậy mọi khách hàng chỉ có thể thực sự truy cập vào thư mục riêng của mình, mặc dù các chuỗi khác "ở đâu đó trong bóng tối".

chế độ d - x - x-- trên thư mục tối đảm bảo rằng mọi khách hàng đều có thể nhập thư mục (và các thư mục bên dưới), nhưng không thể liệt kê nội dung của nó hoặc tạo bất kỳ mục mới nào.

Các thư mục con được tạo bởi quá trình máy chủ dự phòng và kết nối giữa máy khách và thư mục được lưu trữ (trong số những thứ khác) trong một db sqlite.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.