Điểm:3

Setting up sftp on Amazon Linux 2 with ssh keys, user segregation (sftp vs ssh), different ports, and user directory constraints

lá cờ pk

TDLR: I have a Catch 22 where, depending on permissions on the user's home directory, I can get the SSH authentication to work, or the user directory constraints, but not both.

BTW, I really want to roll my own SFTP server. Please don't recommend I try AWS Transfer service or something alternative. Thanks.

Here is relevant (changed from default) content in /etc/ssh/sshd_config:

Subsystem sftp internal-sftp
Port 22
Port 2299
Match Group sftpusers LocalPort 2299
  ChrootDirectory /sftp-data/%u
  ForceCommand internal-sftp
Match Group sftpusers LocalPort 22
  DenyGroups sftpusers
Match LocalPort 2299  Group *,!sftpusers
  DenyUsers *

I want port 22 functioning as ssh typically does, but only for non-sftp users. For sftp users, in group "sftpusers", I want port 2299 to function as sftp only, and not ssh. For non-sftpusers, I want access to port 2299 denied.

Ok, so, I created a user "user1" with home directory /sftp-data/user1 and shell /sbin/nologin. I created /sftp-data/user1/.ssh/authorized_keys and populated that with the public ssh key. /sftp-data is owned by root with 700 permissions. /sftp-data/user1/.ssh and below are owned by user1, and /sftp-data/user1/.ssh/authorized_keys has permission 600. The ownership/permissions of /sftp-data/user1 are under question here. More below.

I created the user group sftpusers and added user1 to that group. The built-in ec2-user you get with AWS is not a member of that group, however. Testing with ec2-user worked great: access via ssh, port 22 worked as it always does, but no access to port 2299.

So, testing with user1 is where it got interesting. User1 has no access to port 22 - that's great! With user1 owning /sftp-data/user1, the ssh public key authentication succeeds on port 2299, but the user is immediately logged out, with this message saved in /var/log/secure:

Sep  2 19:21:38 ip-192-168-0-25 sshd[10369]: Accepted publickey for user1 from <ip-address redacted> port 61110 ssh2: ECDSA SHA256:<sha redacted>
Sep  2 19:13:23 ip-192-168-0-25 sshd[9803]: pam_unix(sshd:session): session opened for user user1 by (uid=0)
Sep  2 19:13:23 ip-192-168-0-25 sshd[9803]: fatal: bad ownership or modes for chroot directory "/sftp-data/user1" [postauth]
Sep  2 19:13:23 ip-192-168-0-25 sshd[9803]: pam_unix(sshd:session): session closed for user user1

Sure, that makes sense. Chroot requires /sftp-data/user1 to be owned by root, permissions 700. So, make that so, and now the sftp (ssh key) authentication fails.

Sep  2 19:41:00 ip-192-168-0-25 sshd[11693]: error: AuthorizedKeysCommand /opt/aws/bin/eic_run_authorized_keys user1 SHA256:<sha redacted> failed, status 22

BTW, eic_run_authorized_keys is a wrapper AWS puts around standard ssh authentication to enable AWS Instance Connect.

For extra credit... if the above problem is not challenging enough, can you come up with a scheme where I can give particular sftp users access to particular project directories, and only those, without creating a group for every project? Link from each user's home directory to a project directory would be awesome.

Additional info requested by @anx:

# getent passwd user1
user1:x:1001:1001::/sftp-data/user1:/sbin/nologin
# namei -l /sftp-data/user1/.ssh/authorized_keys
f: /sftp-data/user1/.ssh/authorized_keys
dr-xr-xr-x root  root      /
drwxr-xr-x root  root      sftp-data
drwx------ root  root      user1
drwx------ user1 sftpusers .ssh
-rw------- user1 sftpusers authorized_keys

I turned on DEBUG logging for sshd. Using the ChrootDirectory directive, with /sftp-data/user1 owned by root, and SSH authentication failing, I see this in /var/log/secure:

debug1: Could not open authorized keys '/sftp-data/user1/.ssh/authorized_keys': Permission denied

ps clearly shows me that root is running the sshd process.

lá cờ pk
@anx cảm ơn vì những suy nghĩ. Tập lệnh eic_run_authorized_keys của AWS đang cố kiểm tra một khóa trong siêu dữ liệu của phiên bản EC2 để xem liệu EC2 Instance Connect có đang được sử dụng hay không. Tập lệnh đó được chỉ định trong tệp sshd_config trong AuthorizedKeysCommand. Trang hướng dẫn trên đó có nội dung: "Nếu khóa do AuthorizedKeysCommand cung cấp không xác thực thành công và ủy quyền cho người dùng thì xác thực khóa chung sẽ tiếp tục sử dụng các tệp AuthorizedKeysFile thông thường." Vì vậy, nó không thành công với trạng thái 22 trên lệnh cuộn tròn trả về trạng thái 401. Sau đó, xử lý thông thường với ~user1/.ssh/authorized_keys go
lá cờ pk
Theo đề xuất của @ anx, tôi đã tạo một trường hợp đơn giản hơn. Kịch bản hoạt động là xóa chỉ thị ChrootDirectory khỏi sshd_config và user1 có quyền sở hữu /sftp-data/user1. Điều đó, tất nhiên, không làm những gì tôi muốn. Để thêm vào Chroot, root phải sở hữu /sftp-data/user1, nếu không sẽ xảy ra lỗi trên đó. Khi root sở hữu thư mục đó, xác thực SSH không thành công.
Michael Hampton avatar
lá cờ cz
Lỗi nào đã được sshd ghi lại cho tập hợp quyền cụ thể đó?
lá cờ pk
câu hỏi được cập nhật - với chi tiết đó @MichaelHampton
Michael Hampton avatar
lá cờ cz
ChrootDirectory của bạn cần có quyền tìm kiếm tối thiểu (`a+x`) để người dùng không có đặc quyền có thể truy cập vào các thư mục cấp thấp hơn.
lá cờ pk
@MichaelHampton bạn hiểu rồi. Tạo một câu trả lời nếu bạn muốn. Tôi đã đọc quá nhiều những gì trang hướng dẫn nói về ChrootDirectory: "Khi khởi động phiên, sshd (8) kiểm tra xem tất cả các thành phần của tên đường dẫn có phải là các thư mục thuộc sở hữu gốc không được ghi bởi bất kỳ người dùng hoặc nhóm nào khác không". Vì vậy, có vẻ như những gì chúng tôi đã học được là sshd đang kiểm tra tệp ủy quyền có thể được đọc khi người dùng cố gắng xác thực. Cảm ơn nhiều!
Điểm:3
lá cờ cz

Của bạn Thư mục Chroot/sftp-data/user1, phải được sở hữu bởi root. Và đó là:

# namei -l /sftp-data/user1/.ssh/authorized_keys
f: /sftp-data/user1/.ssh/authorized_keys
gốc dr-xr-xr-x /
drwxr-xr-x root root sftp-data
drwx ------ root user1
drwx ------ user1 sftpusers .ssh
-rw------- user1 sftpusers ủy quyền_keys

Tuy nhiên, tại thời điểm này, sshd đã thay đổi người dùng thành user1 và bỏ các đặc quyền, vì vậy user1 không thể xuống các thư mục cấp thấp hơn. Để làm điều đó, thư mục cần có quyền tìm kiếm (a+x).

chmod a+x /sftp-data/user1

Bây giờ user1 có thể xuống các thư mục con và .ssh thư mục nên có thể đọc được.

Điểm:1
lá cờ ve

Tôi nghĩ rằng đây chủ yếu là vấn đề về quyền đối với thư mục. tôi nghĩ vậy /sftp-data/user1/.ssh và các thư mục bên dưới nó phải được sở hữu bởi người dùng1, nhưng có vẻ như chúng thuộc sở hữu của nguồn gốc. Hãy thử như sau nguồn gốc:

Xác minh khóa công khai trong /sftp-data/user1/.ssh/authorized_keys là chính xác. Sau đó, tôi nghĩ đây là những quyền bạn có thể cần thay đổi:

chmod 700 /sftp-data/user1/.ssh
chmod 600 /sftp-data/user1/.ssh/authorized_keys
chown root:sftpusers /sftp-data
chown -R user1:user1 /sftp-data/user1/.ssh

Khởi động lại SSH và tôi nghĩ bạn sẽ ổn thôi.

lá cờ pk
Cảm ơn vì câu trả lời. Thật không may, tôi đã thử các quyền đó rồi. Để đề phòng, tôi đã chạy các lệnh được đề xuất của bạn và tìm thấy kết quả tương tự. Xác thực SSH không thành công. Tôi đang nghĩ, về mặt logic, điều gì có thể khác với giải pháp thay thế, nơi user1 sở hữu/sftp-data/user1? Có thể nào sshd (chạy bằng root) không thể truy cập các khóa được ủy quyền của người dùng vì nó đang duyệt các thư mục?

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.