Настройка sftp в Amazon Linux 2 с ключами ssh, разделением пользователей (sftp vs ssh), разными портами и ограничениями каталога пользователей

TDLR: у меня есть Catch 22, где, в зависимости от разрешений в домашнем каталоге пользователя, я могу заставить работать аутентификацию SSH или ограничения каталога пользователя, но не то и другое вместе .

Кстати, я действительно хочу запустить свой собственный SFTP-сервер. Пожалуйста, не рекомендую пробовать сервис AWS Transfer или что-то другое. Спасибо.

Вот релевантное (измененное по умолчанию) содержимое в / 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 *

Я хочу, чтобы порт 22 работал как обычно ssh, но только для пользователей, не использующих sftp. Для пользователей sftp в группе sftpusers я хочу, чтобы порт 2299 работал только как sftp, а не ssh. Для пользователей, не использующих sftpusers, я хочу, чтобы доступ к порту 2299 был запрещен.

Итак, я создал пользователя «user1» с домашним каталогом / sftp-data / user1 и оболочкой / sbin / nologin. Я создал /sftp-data/user1/.ssh/authorized_keys и заполнил его открытым ключом ssh. / sftp-data принадлежит пользователю root с разрешениями 700. /sftp-data/user1/.ssh и ниже принадлежат пользователю user1, а /sftp-data/user1/.ssh/authorized_keys имеет разрешение 600. Право собственности / разрешения / sftp-data / user1 здесь находится под вопросом. Подробнее ниже.

Я создал группу пользователей sftpusers и добавил в нее пользователя user1. Однако встроенный ec2-пользователь, которого вы получаете с AWS, не является членом этой группы. Тестирование с пользователем ec2 прошло отлично: доступ через ssh, порт 22 работал, как всегда, но нет доступа к порту 2299.

Итак, тестирование с пользователем user1 стало интересным.User1 не имеет доступа к порту 22 - это здорово! Когда user1 владеет / sftp-data / user1, аутентификация с открытым ключом ssh проходит успешно на порту 2299, но пользователь немедленно выходит из системы, и это сообщение сохраняется в / 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

Конечно, это имеет смысл. Chroot требует, чтобы / sftp-data / user1 принадлежал пользователю root, права доступа 700. Итак, сделайте это так, и теперь аутентификация sftp (ключ ssh) не выполняется.

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

Кстати, eic_run_authorized_keys - это оболочка, которую AWS использует для стандартной аутентификации ssh для включения AWS Instance Connect.

В качестве дополнительной благодарности ... если вышеуказанная проблема не является достаточно сложной, можете ли вы придумать схему, по которой я могу предоставить отдельным пользователям sftp доступ к определенным каталогам проектов, и только к ним, без создания группы для каждого проекта? Ссылка из домашнего каталога каждого пользователя в каталог проекта была бы замечательной.

Дополнительная информация, запрошенная @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

Я включил ведение журнала DEBUG для sshd. Используя директиву ChrootDirectory, с / sftp-data / user1, принадлежащим root, и неудачной аутентификацией SSH, я вижу это в / var / log / secure:

debug1: Не удалось открыть авторизованные ключи '/ sftp-data / user1 / .ssh / authorized_keys ': Permission denied

ps ясно показывает мне, что root выполняет процесс sshd.