Linux запретить пользователю локальный вход

Как запретить пользователю входить в систему, но разрешить «su — user» в Linux?

Как вы разрешаете пользователю входить в систему, используя « su — пользователь », но не позволяя пользователю войти в систему, используя SSH?

Я попытался установить оболочку, /bin/false но когда я пытаюсь, su она не работает.

Есть несколько способов разрешить вход только su ?

SSH — AllowUser это путь? (как бы я это сделал, если это путь)

Вы можете использовать AllowUsers / AllowGroups, если у вас есть только несколько пользователей / групп, которым разрешен вход через ssh или DenyUsers / DenyGroups, если у вас есть только несколько пользователей / групп, которым не разрешен вход. Обратите внимание, что это ограничивает вход только через ssh, другие способы входа (console, ftp, . ) все еще возможны. Вам необходимо добавить эти опции в ваш файл / etc / ssh / sshd_config для большинства установок ssh.

Если вы установили оболочку входа в систему / bin / false, которую вы можете использовать su -s /bin/bash user (замените / bin / bash на выбранную вами оболочку)

Если вы все еще хотите, чтобы su работал, вы можете использовать sudo -u [username] или передать -s /bin/bash su как временную оболочку. Они оба делают то же самое в отсутствие оболочки в /etc/passwd .

Если у учетной записи нет пароля ( passwd -d username ), они не могут войти в систему в интерактивном режиме (консоль, SSH и т. Д.). Если у них есть корректная оболочка, su все равно будет работать. Обратите внимание на «в интерактивном режиме», хотя; если кто-то решит настроить пару ключей SSH для учетной записи, она будет работать!

] # su daemon Эта учетная запись в настоящее время недоступна. [root @ localhost

] # su — daemon Эта учетная запись в настоящее время недоступна. (Система RHEL, оболочка демона — / sbin / nologin)

В sshd_config добавьте строку DenyUser [username]

Обратите внимание, что это не помешает этому пользователю войти в систему через консоль.

В дополнение к тому, что было упомянуто выше (отключите и / или не устанавливайте пароль пользователя), модуль pam_access (посмотрите справочную страницу в pam_access и access.conf) можно использовать для управления доступом для входа в систему.

как говорили другие;

DenyUser username или DenyGroup groupname в sshd_config предотвратит KeyPair / пароль входа через SSH.

хотя обычно я делаю что-то подобное AllowGroup ssh или что-то в этом роде и явно добавляю людей, которым нужен ssh-доступ к этой группе.

затем вы можете сделать то, что сказали другие: passwd -d username удалить пароль пользователя, чтобы он не мог войти в систему с консоли, или каким-либо другим способом. или еще лучше, passwd -l username чтобы заблокировать учетную запись. Возможно, SSH запретит доступ к заблокированной учетной записи, даже с ключами, но я не уверен.

Как я уже упоминал в комментарии, я думаю, что вы все равно можете использовать su для учетной записи с неверной оболочкой. Поэтому, если вы установите для оболочки пользователя значение / dev / null или что-то вроде оболочки bin, вы сможете использовать su для этого пользователя . но любая попытка войти любым способом приведет к выходу из строя .

отредактируйте / etc / shadow, добавив! к началу хэша пароля.

При обеспечении новой установки это первое, что я делаю после установки sudo, поэтому никто не может использовать пользователя root для входа в систему или входа в систему через ssh, пользователи sudo могут по-прежнему работать от имени пользователя root.

Не указывайте пароль для пользователя, которому запрещено входить в систему или удалять его.

Источник

Как ограничить доступ пользователя в Linux

Как ограничить доступ пользователя в Linux

Представьте себе этот сценарий. Вы хотите разрешить пользователю выполнять только определенные задачи и выполнять определенные команды. Пользователь не должен изменять переменные / пути окружения. Он / она не может посещать другие каталоги, кроме своего домашнего каталога, и не может переключаться на других пользователей и т. Д. Пользователь может выполнять только несколько команд, назначенных системным администратором. Это возможно? Да! Здесь на помощь приходит Restricted Shell . Используя Restricted Shell, мы можем легко ограничить доступ пользователя к системе Linux. После того, как вы поместите пользователей в ограниченный режим оболочки, им разрешено выполнять только ограниченный набор команд. В этом кратком руководстве мы поговорим о том, как это сделать в Linux. Я тестировал это руководство на минимальном сервере CentOS 7. Однако он будет работать в большинстве Unix-подобных дистрибутивов.

Что такое Restricted Shell?

Во-первых, позвольте мне пояснить, что такое Restricted Shell. Это не отдельная оболочка, такая как Bash, Korn Shell и т. Д. Если вы запустите любую существующую оболочку, используя параметры «rbash», «—restricted», «-r», она станет оболочкой с ограничениями. Например, оболочку Bourne можно запустить как оболочку с ограниченным доступом с помощью команды bsh -r , а оболочку Korn — с помощью команды ksh -r .

• Это не позволит вам выполнить команду cd . Так что никуда не денешься. Вы можете просто оставаться в текущем рабочем каталоге
• Это не позволит вам изменять значения переменных окружения $PATH, $SHELL, $BASH_ENV или $ENV environmental variables.
• Это не позволит вам выполнить программу, содержащую символ / (косая черта). Например, вы не можете запустить команду /usr/bin/uname или ./uname . Однако вы можете выполнить команду uname. Другими словами, вам разрешено запускать команды только по текущему пути
• Вы не можете перенаправить вывод, используя ‘ > ’, ‘ >| ’, ‘ <> ’, ‘ >& ’, ‘ &> ’, and ‘ >> ’ операторы перенаправления.
• Это не позволит вам выйти из ограниченного режима оболочки в сценариях.
• Это не позволит вам отключить ограниченный режим оболочки с помощью ‘set +r’ или ‘set +o restricted’.

Это может быть очень полезно, когда большое количество пользователей используют общую систему. Итак, если вы хотите разрешить пользователям выполнять только определенные команды, Restricted Shell — один из способов сделать это.

Ограничьте доступ пользователей к системе Linux с помощью оболочки с ограничениями

Сначала создайте символическую ссылку под названием rbash из Bash, как показано ниже. Следующие команды следует запускать от имени пользователя root .

Затем создайте пользователя с именем «infoit» c rbash качестве его / ее оболочки входа по умолчанию.

Установите пароль для нового пользователя.

Создайте каталог bin внутри домашней папки нового пользователя.

Теперь нам нужно указать, какие команды может запускать пользователь.

Здесь я позволю пользователю запускать только команды «ls» , «mkdir» и «ping» . Вы можете назначить любые команды по вашему выбору.

Для этого выполните следующие команды:

Теперь вы понимаете, почему мы создали каталог bin на предыдущем шаге. Пользователи не могут запускать никакие команды, кроме трех вышеуказанных команд.

Затем запретите пользователю изменять .bash_profile .

Отредактируйте файл /home/infoit/.bash_profile :

Измените PATH как показано ниже.

Нажмите клавишу ESC и введите : wq, чтобы сохранить и закрыть файл.

Теперь, когда пользователь входит в систему, ограниченная оболочка (rbash) будет запускаться как оболочка входа по умолчанию и читать .bash_profile , который установит PATH в $HOME/bin, чтобы пользователь мог запускать только ls , mkdir и команды ping . Оболочка с ограничениями не позволяет пользователю изменять PATH , а разрешения на .bash_profile не позволяют пользователю изменять среду, чтобы обойти ограничения во время следующего сеанса входа в систему.

Проверка Rbash

Теперь выйдите из системы от имени пользователя root и снова войдите в систему с вновь созданным пользователем, в нашем случае с ostechnix.

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

Для этого я запустил:

Sample output:

Вы не можете использовать команду cd для перехода в другой каталог.

Пример вывода:

Вы также не можете перенаправить вывод с помощью оператора >.

Пример вывода:

Пользователь «infoit» может использовать только команды, назначенные вами (системным администратором, конечно). В нашем случае пользователь может выполнять команды ls, mkdir и ping.

Кроме этих трех команд, пользователь ничего не может выполнять. Он / она полностью под вашим контролем.

Разрешить пользователям новые команды

Если вы хотите назначить пользователю больше команд, выйдите из системы текущего пользователя и снова войдите в систему как пользователь root и назначьте команды, как показано ниже.

Например, чтобы позволить пользователю (т.е. ostechnix) выполнять команду rm , выполните следующую команду от имени пользователя root .

Теперь пользователь может использовать команду «rm».

Для получения дополнительных сведений см. Справочные страницы по приведенной ниже ссылке.

Источник

Ограничение прав локального пользователя в Linux до минимума

Как то раз появилась следующая задача: создать локального пользователя в ОС Linux, с ограниченным доступом к папкам и файлам, включая не только редактирование, но и просмотр, а также возможность использовать только разрешенные утилиты. Предусматривается только локальный доступ, сетевого доступа нет.

Что бы не изобретать велосипед, первым делом начал копать интернет, в результате чего были найдены следующие варианты:

• ограничения доступа через сетевые службы ssh, sftp (не подошло)
• разграничение прав доступа самой операционной системой linux (не подошло, хотелось бы универсальное решение)
• использование chroot (не подошло)
• использование сторонних утилит, например SELinux (не подошло, усложняет систему).

В результате поиска, был найден встроенный механизм ограничения возможностей пользователя внутри оболочки bash, он называется Restricted Shell или rbash.

В нем реализованы следующие ограничения:

• нет возможности смены каталога командой cd
• нельзя сбрасывать или изменять значения переменных SHELL, PATH, ENV, BASH_ENV
• запрещено указывать команды содержащие / (косую черту)
• запрещено импортировать функции из основной оболочки
• запрещено перенаправлять вывод с использованием операторов >, , >&, &>, >>
• запрещено использовать команду exec для подмены команды и пр.

Есть минус, это безопасность, поэтому необходимо в обязательном порядке добавить alias на команды в файл поведения оболочки .bashrc (информация будет далее).

Конечно rbash из коробки, всех задач не решает, поэтому на примере рассмотрим создание пользователя и настройка его окружения для полного решения нашей задачи.

Далее все операции выполняются от суперпользователя (root).

1. Создаем ограниченную оболочку

2. Создаем пользователя

3. Изменяем права директории

4. Переходим в директорию и очищаем ее

5. Настраиваем оболочку и права

Файл .bashrc определяет поведение командной оболочки, в данный файл можно добавить alias для команд или дополнительные опции.

Для обеспечения безопасности выполните следующие команды:

Данный список можно продолжать…

6. Проверяем работу

7. Добавляем допустимые команды

Важно, пути в команде ln необходимо указывать полностью.

8. Для ограничения опций команды можно использовать обертки

9. Для работы с файлами и папками можно также создать обертку
с черным списком (разрешить все, кроме):
— создаем файл

blacklist — переменная содержащая черный список директорий или файлов (через пробел)
— добавляем команду для пользователя zuser

Данный скрипт разрешает выполнять команду ls с любыми ключами для каталогов и файлов не совпадающих с черным списком

с белым списком (запретить все, кроме):
— создаем файл

whitelist — переменная содержащая белый список директорий или файлов (через пробел)
— добавляем команду для пользователя zuser

Данный скрипт разрешает выполнять команду cat с указанными файлами в белом списке

Готово, в итоге получили следующий результат:

• мы создали пользователя zuser с оболочкой rbash
• отключили возможность использования автодополнения в консоли
• zuser может запускать утилиты только из директории /home/zuser/bin
• добавили пользователю zuser команду ping
• добавили пользователю zuser собственную команду user-info
• пользователю zuser ограничили через обертку выполнение команд ls и cat

Данный способ к сожалению не гарантирует 100% безопасность, и при определенных знаниях и квалификации пользователь может покинуть данную оболочку. Спасибо Jouretz arheops YaDr они в комментариях привели примеры обхода ограничений оболочки.

Источник

Разграничение прав доступа к Linux-системе и её сервисам через доменные группы безопасности с помощью SSSD и PAM

Когда мы рассматривали настройку SSSD на Debian 8 (Jessie) , немного упоминали о возможности ограничения доступа к Linux-системе через группы безопасности в домене Active Directory. Однако рассматриваемый в том случае пример предполагает безусловное глобальное ограничение доступа на уровне всей Linux-системы. То есть, указанная в секции описания домена конфигурационного файла sssd.conf опция simple_allow_groups ограничивает доступ не только для входа в систему, но и для всех других служб внутри этой системы, которые будут использовать возможности SSSD. Таким образом, рассмотренный ранее пример настройки авторизации с помощью SSSD в Apache точно также, как и другие сервисы, использующие SSSD, будет ограничен глобальной опцией simple_allow_groups . Но как же быть, если доступ к Linux-системе и её отдельным сервисам требует гранулированной настройки? Например, требуется, чтобы право локального и/или удалённого входа в систему имели члены одной доменной группы безопасности, а право доступа к какому-то сайту веб-сервера Apache (или даже отдельному веб-каталогу) имели члены другой группы безопасности домена Active Directory. Попробуем решить эту задачу с помощью настройки механизма подключаемых модулей аутентификации — Pluggable Authentication Modules (PAM), а конкретнее с помощью использования возможностей библиотеки pam_listfile.so .

Отключаем ограничения SSSD

Для начала нам потребуется отключить ограничения по доменным группам безопасности, явно заданные в конфигурации SSSD, если такие ограничения были задействованы ранее. Например, если в конфигурационном файле /etc/sssd/sssd.conf в секции, описывающей домен Active Directory по ранее рассмотренному примеру было задано ограничение для конкретной доменной группы безопасности…

То теперь мы можем отключить такое ограничение, заменив соответствующие параметры на такой вариант:

После внесённых изменений выполним перезапуск службы sssd с очисткой кеша:

Таким образом мы отключим глобальное ограничение, нацеленное на определённую доменную группу безопасности и все службы, которые используют аутентификацию/авторизацию из SSSD, можно будет отдельно настроить на ограничение отдельных групп безопасности.

Общий принцип настройки политик PAM для разных служб

Если мы заглянем в каталог /etc/pam.d/ , то увидим множество файлов, определяющих политики PAM для той или иной службы сервера, умеющей использовать аутентификацию и авторизацию с помощью PAM. Структура файлов в этом каталоге мне больше нравится в Debian, чем в CentOS, так как более интуитивно понятна и упорядочена. Например, общие для всех параметры в Debian включены в файлы с понятными именами common- ( common-auth , common-account , common-password и т.п.). Эти файлы в свою очередь подключены в файлах, касающихся отдельных служб, например login или sshd (в них присутствуют строки типа @include common-auth ). Таким образом, воздействовать на настройки PAM для разных служб можно как на глобальном уровне, изменяя файлы /etc/pam.d/ common- , так и на уровне отдельных служб, изменяя конкретные файлы типа /etc/pam.d/ login или /etc/pam.d/ sshd .

Так как нам требуется уникальная настройка ограничения прав доступа для разных служб, то общие файлы типа common-* мы трогать не будем, а будем изменять конфигурационные файлы PAM для отдельных служб. Для ограничения доступа мы будем использовать возможности библиотеки pam_listfile.so , которую будем вызывать в файлах политик PAM интересующих нас служб в каталоге /etc/pam.d/ .

Читайте также:  You have stopped jobs linux

Библиотека pam_listfile.so – это удобный инструмент, который, в частности, позволяет выполнять проверку вхождения пользователя в группу, которая указана во внешнем файле. В таком внешнем файле могут быть указаны как локальные по отношению к серверу группы, так и группы безопасности из домена Active Directory, список которых, в свою очередь, нам помогает получать sssd. Файл групп может содержать как одну группу, так и несколько (по одной группе в каждой отдельной строке). При этом в одном файле можно комбинировать как локальные, так и доменные группы.

Далее мы рассмотрим пример того, как подобным образом настроить PAM-политику для локального входа на сервер ( /etc/pam.d/login ), подключения к серверу SSHD ( /etc/pam.d/sshd ) и доступа к сайту веб-сервера Apache (создадим собственный файл политик PAM).

Настраиваем PAM для ограничения доступа на локальный вход в систему

Создадим файл для хранения списка групп, которым мы хотим предоставить право локального входа в систему. Обязательно ограничим доступ к этому файлу:

Наполним файл группами, по одной в каждой строчке. Обязательно укажем системные локальные группы типа root и adm, чтобы ненароком не отобрать доступ к серверу у локальных административных учётных записей Linux, затем перечислим нужные доменные группы безопасности:

Теперь файл групп подключим к политике PAM в конфигурационном файле /etc/pam.d/login таким образом, чтобы его использование было инициировано вызовом библиотеки pam_listfile.so .

В данном примере библиотека pam_listfile.so вызывается модулем account, который используется на этапе авторизации. Набор параметров ( onerr=fail item=group sense=allow ) определяет то, что авторизация считается не успешной, если проверяемый пользователь не входит ни в одну из перечисленных в указанном файле групп ( file=/etc/access-groups-to-system ). При этом желательно учитывать порядок вызова модулей в файле политик PAM, то есть вызов нашей проверки членства в группе можно сделать до того, как идёт стандартная обработка модулей account (подключаемых в данном конкретном примере из common-account ).

Перед правкой файлов PAM важно учитывать то, что любая некорректная их правка может привести к тому, что мы заблокируем доступ к системе. Поэтому пока правим и отлаживаем эти файлы лучше не закрывать текущую сессию администратора, а проверки делать, используя отдельные дополнительные подключения, чтобы у нас была возможность исправления возможных проблем.

Итак, попробуем залогиниться на консоль сервера, используя учётную запись пользователя, входящего в разрешённую нами доменную группу. При этом наблюдаем за логом auth.log . В случае успешной аутентификации и авторизации увидим примерно следующее:

Теперь попробуем залогиниться, используя любую другую доменную учётную запись пользователя, заведомо не входящую ни в одну из разрешённых групп:

Как видим, этап аутентификации прошёл успешно, то есть учётные данные пользователя проверены, однако на этапе авторизации доступ был заблокирован.

Аналогичным образом рекомендуется проверить не только доступ доменных учётных записей, но и доступ локальных административных записей Linux, чтобы у нас всегда оставалась возможность подключения к серверу, даже если с sssd возникнут какие-то проблемы и доменная аутентификация вдруг перестанет работать.

Настраиваем PAM для ограничения доступа к серверу SSHD

Аналогичным образом можем настроить доступ к службе сервера sshd. Для этого нам потребуется внести изменения в файл политик PAM для этой службы — /etc/pam.d/sshd .

Здесь мы уже можем использовать другой файл для хранения групп доступа. Однако учитывая то, что к sshd обычно имеют доступ те же пользователи, что имеют право локального входа на сервер мы будем указывать тот же файл, что использовали для политик PAM в конфигурационном файле /etc/pam.d/login .

В конфигурационном файле настроек службы sshd ( /etc/ssh/sshd_config ) в конфигурации по умолчанию уже имеется опция разрешающая использовать аутентификацию с помощью PAM:

Поэтому никаких дополнительных настроек в системе делать не потребуется.

И также как, в случае с ранее рассмотренной настройкой локального входа, проверяем для службы sshd возможность аутентификации доменным пользователем из разрешённой группы доступа, прочим доменным пользователем, а также локальным пользователем Linux.

Настраиваем PAM для ограничения доступа к сайту веб-сервера Apache

Теперь рассмотрим более сложный пример с ограничением доступа к некому сайту веб-сервера Apache, который работает на нашем Linux-сервере. Предположим, что к сайту должны иметь доступ доменные пользователи, входящие в группу безопасности KOM-SRV-WebApp1-Operators .

Сначала создадим файл, содержащий группы доступа к нашему веб-сайту (например /etc/access-groups-to-apache2-webapp1 ) и ограничим права доступа к нему:

Затем создадим и настроим файл выделенной политики PAM для нашего веб-приложения (например /etc/pam.d/apache2-webapp1 ), сделав в нём ссылку на файл групп следующим образом:

Теперь созданную политику PAM можем подключать в конфигурации сайта веб-сервера Apache. Например, при использовании Kerberos-аутентификации вместо зачастую используемого условия Require valid-user , мы можем использовать условие типа Require pam-account :

После изменения конфигурации сайта Apache для вступления изменений в силу можно перезагрузить службу веб-сервера:

Источник