Q&A Настройка 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: Could not open authorized keys '/sftp-data/user1/.ssh/authorized_keys': Permission denied

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

answer

Ваш ChrootDirectoryis /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каталог должен быть доступен для чтения.

Я думаю, что это в первую очередь проблема с правами доступа к папке. Я думаю, что это /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, и я думаю, вам будет хорошо.