Мне нравится следующая установка для управления доступом по SSH, которую я использовал для управления группой пользователей на небольшом парке серверов. Безопасность и простота управления занимают одно из первых мест в списке моих приоритетов.
Его ключевыми особенностями являются простое управление правами SSH через членство в группе Unix, наличие жестко определенных разрешений и безопасность по умолчанию.
Установка программного обеспечения (необязательно, но полезно):
yum install members # or apt install members
Добавить группы:
addgroup --system allowssh
addgroup --system sftponly
В /etc/ssh/sshd_config
убедитесь, что следующие настройки установленыNo
:
PermitRootLogin no
PubkeyAuthentication no
PasswordAuthentication no
И в конце /etc/ssh/sshd_config
добавить эти две строфы:
Match Group allowssh
PubkeyAuthentication yes
Match Group sftponly
ChrootDirectory %h
DisableForwarding yes
ForceCommand internal-sftp
(не забудьте перезапустить SSH после редактирования файла)
Итак, что все это делает?
allowssh
. sftponly
не могут получить оболочку через SSH, только через SFTP. Управление доступом осуществляется просто путем управления членством в группе. (Изменения членства в группе вступают в силу немедленно, перезапуск SSH не требуется; но обратите внимание, что существующие сеансы не затрагиваются ). members allowssh
покажет всех пользователей, которым разрешен вход через SSH, а members sftponly
покажет всех пользователей, которым разрешен доступ к SFTP.
# adduser marcelm allowssh
# members allowssh
marcelm
# deluser marcelm allowssh
# members allowssh
#
Обратите внимание, что ваши пользователи sftp должны быть членами как sftponly
(, чтобы гарантировать, что они не получат оболочку ), так и allowssh
(, чтобы разрешить вход в систему в первую очередь ).
Обратите внимание, что эта конфигурация не позволяет входить в систему с паролем ; все учетные записи должны использовать аутентификацию с открытым ключом. Это, вероятно, самая большая победа в безопасности, которую вы можете получить с помощью SSH.поэтому я утверждаю, что это стоит усилий, даже если вам нужно начать сейчас.
Если вы действительно этого не хотите, то также добавьте PasswordAuthentication yes
к строфе Match Group allowssh
. Это позволит пользователям allowssh
авторизоваться как по публичному ключу, так и по паролю. Кроме того, вы можете добавить еще одну группу (и Match Group
строфу ), чтобы выборочно предоставлять пользователям вход на основе пароля -.
Эта конфигурация ограничивает любого sftponly
пользователя своим домашним каталогом. Если вы этого не хотите, удалите директиву ChrootDirectory %h
.
Если вы действительно хотите, чтобы chroot работал, важно, чтобы домашний каталог пользователя (и любой каталог над ним )принадлежал root:root
и не был доступен для записи группе/другим. Подкаталоги домашнего каталога могут принадлежать пользователю -и/или доступны для записи.
Да, домашний каталог пользователя должен принадлежать пользователю root -и быть недоступным для записи пользователю. К сожалению, для этого ограничения есть веские причины . В зависимости от вашей ситуации хорошей альтернативой может быть ChrootDirectory /home
.
Установка оболочки sftponly
пользователей на /sbin/nologin
не является ни необходимой, ни вредной для этого решения, поскольку ForceCommand internal-sftp
SSH переопределяет оболочку пользователя.
Тем не менее, использование /sbin/nologin
может помочь остановить их вход в систему с помощью других способов (физической консоли, Samba и т. д. ).
Эта настройка не разрешает прямой root
вход через SSH; это формирует дополнительный уровень безопасности. Если вам действительно действительно нужны прямые входы в систему root, измените директиву PermitRootLogin
. Попробуйте установить его на forced-commands-only
, prohibit-password
и (в крайнем случае)yes
.
Чтобы получить бонусные баллы, обратите внимание на ограничение su
доступа к root-доступу; добавьте системную группу с именем wheel
и добавьте/включите auth required pam_wheel.so
в /etc/pam.d/su
.
Исходный код PureOS доступен здесь :http://repo.pureos.net/pureos/pool/main/. Копание в исходном коде и/или установка дистрибутива и анализ сетевого трафика являются лучшими прямыми способами определения безопасности дистрибутива.
Для большинства людей это невыполнимо, поэтому нам придется применить эвристический подход.
PureOS основана на Debian, у которого «много глаз» на коде, и хотя производные теоретически могут вносить любые модификации, которые они хотят, с доступным кодом и такими вещами, как проверка соответствия FSF, хотя и не невозможно, я бы сказал, что это маловероятно, что этот дистрибутив представляет собой исключительную угрозу вашей конфиденциальности.
Недавняя -некоторая активность в системе отслеживания ошибок :https://tracker.pureos.net/, и это хорошо. Может показаться пугающим видеть этот большой список ошибок, но с миллионами строк кода в дистрибутиве они есть у каждого, и активные попытки устранить ошибки — лучший признак, чем бездействие (, что указывает на безразличие ).
Если у вас нет исключительных потребностей в безопасности, которые потребуют «усиленного», -ориентированного на безопасность дистрибутива, такого как Qubes, могу поспорить, что с PureOS все в порядке. Кроме того, его основной аргумент в пользу «Все бесплатное программное обеспечение», поэтому в нем нет неразборчивых двоичных двоичных объектов.