☰

Как запретить пользователям вмешиваться в работу собственной папки .ssh?

tag-icon • tag-icon permissions ssh-keys
Как запретить пользователям вмешиваться в работу собственной папки .ssh?

Я администрирую сервер RedHat, на котором пользователи входят через SSH с аутентификацией на основе закрытого/открытого ключа.

Я бы хотел предотвратить случайное изменение/удаление/редактирование содержимого их~/.sshпапки. Некоторые из них уже рекурсивно установили 777-chmoder для всей своей домашней папки, потому что «так было проще делиться файлами с коллегами», и выстрелили себе в ногу.

Есть идеи, как этого добиться? Желательно со стандартной системой разрешений Linux.

решение1

Короткий ответ — нет.

SSH очень требователен к разрешениям и не будет играть с файлами, которые ему не нравятся. Кроме того, пользователи ssh_configанализируютсядообщесистемная конфигурация.

Сказав это, онможетможно ли поместить файлы в другое место и смонтировать каталог как файловую систему только для чтения $HOME/.sshдля каждого пользователя. (Это возможно, но я не знаю, как ssh и связанные с ним инструменты отреагируют на это).

Некоторые из них уже рекурсивно установили 777-chmoder для всей своей домашней папки.

Тогда у вас возникнут гораздо большие проблемы с БЕЗОПАСНОСТЬЮ и обучением.

решение2

Трудно защитить пользователей от их собственного невежества и некомпетентности.

Но в зависимости от того, насколько вам необходимо разрешить пользователям управлять самостоятельно и насколько вы управляете за них: вы можете настроить sshd на поиск ключей в альтернативном месте за пределами их домашнего каталога и в другом месте, чем ~/.ssh/authorized_keys.

AuthorizedKeysCommand

Относительно сложным решением является/etc/ssh/sshd_config AuthorizedKeysCommand директива, которая вместо использования файлов authorized_keys указывает программу, которая будет использоваться для поиска открытых ключей пользователя, например:

  • аLDAP-каталог

  • абаза данных

  • (тривиальный) веб-сервис

  • или если ваши имена пользователей идентичны именам пользователей Github, вы можете разрешить пользователям проходить аутентификацию с помощью пары(пар) ключей, которые они загрузили туда:

    AuthorizedKeysCommand /usr/bin/curl https://github.com/%u.keys

Как упоминалось вэтот ответ; вам потребуется создать подходящую политику SELinux для AuthorizedKeysCommand, поскольку она блокируется политиками по умолчанию.

Мне нравится этот подход, поскольку он может решить множество проблем, связанных с управлением авторизованными ключами: он добавляет централизованное управление, устраняет проблему курицы и яйца, связанную с получением авторизованных ключей на серверах, когда вы хотите отключить аутентификацию по паролю в ssh, и многое другое.
Он использует тот факт, что открытые ключи не являются особенно чувствительными (в отличие от связанных с ними закрытых ключей), поэтому централизация их управления не добавляет риска, IMHO, и, вероятно, даже улучшает ваши возможности контроля и отчетности.

АвторизованныйКлючФайл

Немного менее сложным является хранение ключей в каталоге за пределами их домашнего каталога. Например, используйте /etc/ssh/<username>(заменив <username>на их фактическое имя пользователя). Этот каталог должен иметь права доступа 755 и принадлежать пользователю. Переместите файл authorized_keysв него. Файл authorized_keys должен по-прежнему иметь права доступа 644 и принадлежать пользователю.

В/etc/ssh/sshd_configнастроитьAuthorizedKeysFileпараметр

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

И перезапустите демон ssh.

решение3

Лучшее решение, которое я могу придумать, — это сделать .sshего authorized_keysвладельцем root.

.ssh / authorized_keys, принадлежащий root

SSH требователен к разрешениям, но не необоснованно. Во-первых, он требует, чтобы сам пользователь имел доступ на чтение authorized_keys(что требует доступа на чтение всех родительских каталогов). Во-вторых, он запрещает доступ, если любой пользователь, кроме самого пользователя или root, имеет доступ на запись в /home, .ssh, или authorized_keys. Это запрещает o+w, и g+wдля группы, в которой есть другие пользователи.

Эта настройка у меня работает, пользователь может войти в систему:

drwxr-xr-x 19 root root 4096 Sep 22 11:24 /
drwxr-xr-x  3 root root 4096 Sep 22 11:19 /home/
drwx------ 14 test test 4096 Sep 22 11:44 /home/test/
drwxr-x---  2 root test 4096 Sep 22 11:42 /home/test/.ssh/
-rw-r--r--  1 root test   98 Sep 22 11:36 /home/test/.ssh/authorized_keys

Поскольку .sshи authorized_keysпринадлежат пользователю root, пользователь не может изменять разрешения на них или удалять их. Они также не могут редактировать свой собственный authorized_keysфайл.

Если вы хотите разрешить пользователю редактировать свой authorized_keys, вы можете добавить разрешения на запись в группу. Для этого требуется, чтобы в testгруппе не было других членов, кроме testнее самой:

-rw-rw-r--  1 root test   99 Sep 22 12:04 /home/test/.ssh/authorized_keys

При любом подходе пользователь больше не может создавать свои собственные файлы в .ssh, поэтому вы можете захотеть предоставить некоторые дополнительные файлы для них. Некоторые из них приходят на ум: known_hosts, config, и id_rsa{.pub,}или другие типы ключей.

Альтернатива: chattr

Некоторые файловые системы Linux поддерживаютатрибуты файла, в частностинеизменный флаг. Файлы/каталоги с установленным флагом неизменяемости не могут быть удалены, изменены или изменены их разрешения. Только root может установить/снять этот флаг.

Эта команда сработает даже с правами собственности/разрешениями по умолчанию:

# chattr +i ~test/.ssh/{authorized_keys,}

Теперь .sshи authorized_keysне может быть изменено каким-либо образом, даже пользователем root. Если root необходимо обновить эти файлы, вам chattr -iсначала нужно будет их обновить. Используйте lsattrдля проверки атрибутов.

Этот подход проще, но менее гибок. Он также требует поддержки файловой системы; я считаю, что он поддерживается как минимум ext2/3/4, XFS и btrfs.

Списки контроля доступа Posix?

Есть такжеСписки контроля доступа Posix(Списки контроля доступа), которые позволяют осуществлять более тонкий контроль. Я не слишком хорошо с ними знаком и не уверен, могут ли они здесь как-то помочь.

Строгие режимы

Примечание:крайне не рекомендуется, но предусмотрено для полноты картины.

OpenSSH-серверимеет директиву конфигурацииназывается StrictModes, который определяет, насколько требователен SSH к разрешениям:

Указывает, должен ли sshd проверять режимы файлов и владельца файлов и домашнего каталога пользователя перед принятием входа. Обычно это желательно, поскольку новички иногда случайно оставляют свой каталог или файлы доступными для записи всем. Значение по умолчанию — yes.

Если вы отключите эту опцию, у вас будет больше свободы в настройке прав собственности и разрешений. Однако SSH по умолчанию строг по понятным причинам. Пользователь, выполняющий 777-chmodding своих файлов SSH, представляет угрозу безопасности.

решение4

Запускайте задание cron для исправления разрешений каждую ночь.

Удаление файлов немного сложнее. Вы также можете восстановить отсутствующие файлы из резервной копии с помощью cron. Но, похоже, вы можете попасть в странные крайние случаи с этим... может потребоваться больше интеллекта, чем может предоставить скрипт. Я бы начал с малого и осторожно добавлял функции в функцию восстановления.

Связанный контент