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

Question

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

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

Вот соответствующее (измененное по сравнению со значением по умолчанию) содержимое в /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-user, который вы получаете с AWS, не является членом этой группы. Тестирование с ec2-user прошло отлично: доступ через 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': Отказано в доступе

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

Answer 1

Ваш ChrootDirectory— /sftp-data/user1, который должен принадлежать пользователю root. И это:

# 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

Однако в этот момент sshd уже изменил пользователя на user1 и сбросил привилегии, поэтому user1 не может спуститься в каталоги более низкого уровня. Для этого каталогу необходимо разрешение на поиск ( a+x).

chmod a+x /sftp-data/user1

Теперь пользователь user1 может переходить в подкаталоги, и .sshкаталог должен быть доступен для чтения.

Answer 2

Я думаю, что это в первую очередь проблема с правами доступа к папкам. Я думаю, что /sftp-data/user1/.sshи каталоги под ним должны принадлежать user1, но звучит так, будто они принадлежат root. Попробуйте следующее как root:

Проверьте, что открытый ключ в /sftp-data/user1/.ssh/authorized_keysверен. После этого, я думаю, вам может понадобиться изменить следующие разрешения:

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

Перезапустите SSH, и я думаю, все будет готово.