Как запретить использование учетной записи для интерактивного входа в Linux
Обновлено: 07.07.2024
Пользователи, которые продолжают входить в виртуальные машины RHEL напрямую в качестве служебных учетных записей, затрудняют отслеживание того, кто что делает.
Есть ли способ запретить конечным пользователям входить в систему напрямую с помощью сервисного аккаунта? Заставить их сначала войти в систему, а затем они смогут перейти к сервисному аккаунту?
Ответы
Это можно сделать, указав pam_access.so в соответствующих файлах конфигурации в /etc/pam.d и установив правила доступа в /etc/security/access.conf.
Вы можете добавить сценарий в /etc/profile.d, который будет сравнивать идентификатор со списком известных учетных записей служб, а затем немедленно отключать их, если будет найдено совпадение.
Я думаю, что самым простым и прямолинейным было бы изменить /etc/passwd с помощью /sbin/nologin для оболочки, таким образом, они будут вынуждены войти в систему со своей учетной записью пользователя, а оттуда могут использовать sudo для служебной учетной записи.
Просто имейте в виду, что этот метод нарушит sudo -i и использование стандартного `su -', поскольку он попытается использовать оболочку пользователя
Добавить запись в /etc/ssh/sshd_config и перезапустить демон sshd, чтобы учетная запись могла быть активной внутри ОС для запуска служб, заданий cron и т. д.,
Чтобы добавить немного больше деталей, чтобы прояснить этот ответ. Для этого подхода сделайте что-то вроде следующего:
Создайте новую группу под названием sshdeny
Отредактируйте файл /etc/ssh/sshd_config и в нижней части/рядом с ним, но ПЕРЕД любыми операторами Match, которые могут быть добавлены:
Следующий перезапуск sshd
Добавьте ролевые учетные записи, для которых вы не хотите входить напрямую через ssh, в группу sshdeny. Вход по SSH для этих учетных записей теперь должен завершаться ошибкой.
Я пытаюсь понять, как сделать так, чтобы учетная запись службы разрешала подключение только по ssh к машинам. Со всеми этими инструкциями, перечисленными выше, у меня ничего не получилось.
Можно предотвратить это с помощью файла профиля, которым управляет puppet или любой другой инструмент управления конфигурацией.
Создайте файл /etc/profile.d/0-no-interactive.sh (ноль в имени файла) со следующим содержимым:
Это предотвратит вход в удаленную и локальную консоль, использование
- su – пользователь 1
- su user1
- sudo su — пользователь1
- sudo su user1
- sudo -u user1 /bin/bash
чтобы получить доступ к оболочке.
Пользователь сможет запускать ansible (даже если требуется пароль sudo) или любые команды через ssh, или пользователь, вошедший в систему, может запускать команды с помощью sudo -u user1, если это необходимо. И, конечно же, вы можете запускать сервисы, используя этих пользователей.
Просто убедитесь, что у вас есть инструмент управления конфигурацией, чтобы его нельзя было удалить/изменить безвозвратно, и было проще поддерживать актуальность списка пользователей на всех серверах.
Есть два предостережения, но я не хочу упоминать их здесь, поэтому потребуется время, чтобы найти их для всех, кто их ищет. :)
Еще один метод (обратите внимание, это обсуждение было начато в 2019 году). Вы можете использовать директивы в /etc/ssh/sshd_config, чтобы запретить определенным пользователям, разделенным пробелами, см. справочную страницу для sshd_config
Моим подходом будет DenyUsers (если только у них нет доступа к консоли!).
В прошлом я просто блокировал учетную запись с помощью команды passwd -l username , но в зависимости от конфигурации SSHD вход будет по-прежнему работать с аутентификацией на основе ключа, если кто-то поместит ключи в домашнюю директорию служебной учетной записи (должен управляться с помощью Puppet!) .
Насколько я помню, параметр -r в useradd всегда предназначался для создания системной учетной записи пользователя. Учетная запись пользователя будет создана в системном диапазоне для использования в службах и т. д. (системный диапазон UID/GID определен в /etc/login.defs ), и PAM предотвратит вход с этих учетных записей. Не уверен, что это все еще соблюдается в конфигурации SSHD, поставляемой RHEL. и, вероятно, это не подходит, если пользователям нужно использовать sudo для учетных записей.
Только что проверил создание системного пользователя с паролем на RHEL 8.5 и смог нормально войти через ssh, что немного разочаровывает.
Иногда необходимо отключить вход пользователей в систему. Например, если вы выполняете техническое обслуживание и хотите, чтобы состояние системы было чистым. В этом кратком совете мы покажем вам, как отключить вход в систему Linux.
Если вы когда-нибудь заглядывали в файл /etc/passwd, скорее всего, вы видели пользовательскую оболочку, установленную в /usr/sbin/nologin. Это сообщает системе, что у этого пользователя нет доступа к интерактивному входу в систему. Это хороший способ заблокировать вход в систему для определенного пользователя, но существует другой файл с именем /etc/nologin, чтобы заблокировать вход в систему любому пользователю без полномочий root.
Блокировка входа всех пользователей без полномочий root в систему
Чтобы запретить вход в систему всем пользователям без полномочий root, просто создайте файл /etc/nologin.
Это заблокирует любого пользователя.Как только они аутентифицируются, соединение будет закрыто. Это часто сбивает пользователей с толку, поэтому рекомендуется добавить сообщение. Просто добавьте сообщение, которое вы хотите отобразить в файл. Вы можете открыть файл в своем любимом текстовом редакторе, таком как vi, nano или emacs, и начать печатать. Или вы можете вывести сообщение в файл следующим образом:
ПРИМЕЧАНИЕ. Вы не можете использовать обычное перенаправление с помощью sudo, поэтому вместо этого мы использовали команду tee.
Теперь, когда пользователь попытается войти в систему, он получит сообщение, и соединение будет закрыто.
Так гораздо вежливее.
Разблокировать логины
Чтобы разблокировать или снова разрешить вход, просто удалите файл /etc/nologin.
Блокировать определенного пользователя от интерактивного входа в систему
Вы можете использовать оболочку nologin, чтобы заблокировать доступ к интерактивной оболочке для определенного пользователя. Это удобно, если вы хотите разрешить пользователю только FTP-доступ или что-то подобное.
Оболочка nologin расположена по разным путям в разных системах.
Для Ubuntu он находится в /usr/sbin/nologin
Для Fedora он находится в /sbin/nologin
Вы можете узнать, где он находится, с помощью команды which:
Чтобы настроить оболочку пользователя на nologin, вы можете использовать команду usermod. Здесь мы установим для пользовательской оболочки "stacy" значение nologin.
Разблокировать доступ определенного пользователя к интерактивному входу
Чтобы разблокировать или снова разрешить пользователю входить в систему через интерактивную оболочку, просто установите для его оболочки обратно bash (или любую другую оболочку по вашему желанию).
Чтобы вернуть оболочку пользователя "stacy" в bash:
Если вы используете "usermod -s" без каких-либо аргументов, система будет использовать для пользователя оболочку по умолчанию.
Заключение
Теперь вы должны знать, как отключить вход пользователей в систему. Мы рассмотрели отключение всех учетных записей пользователей, а также настройки для конкретных пользователей. Не стесняйтесь высказываться в комментариях.
Запретить сервисному аккаунту прямые интерактивные сеансы
Основные форумы UNIX для опытных и опытных пользователей Запретить учетным записям службы прямые интерактивные сеансы
4, 0
Среда: CentOS 7
Я хотел бы иметь решение, в котором учетная запись службы может получить доступ к серверу только следующими способами:
- ssh неинтерактивно через пароль или ключ ssh; то есть запускать команды или сценарии (но запуск чего-либо в /etc/shells будет запрещен)
- не ssh в интерактивном режиме
- обычные пользователи могут su $serviceaccount или иным образом получить интерактивную оболочку
Цель состоит в том, чтобы заставить пользователей входить на сервер как самих себя, а затем переключать пользователей, а также позволять служебному аккаунту взаимодействовать с самим собой через скриптовые процессы с других серверов.
Я уже пробовал эти шаги
На самом деле это ничего не делает, кроме как мешает красивому терминалу. Пользователь по-прежнему получает интерактивную оболочку.
Пользователи могут изменить его, плюс я не могу гарантировать, что каждое соединение использует ключ ssh.
/sbin/nologin: запрещает все входы в систему, кроме "sudo -su $serviceaccount"
/bin/false: полностью завершает работу с ошибкой
/bin/true: вообще не разрешает никаких действий
пользовательский скрипт-оболочка: пользовательский скрипт, который проверяет наличие «$@» и реагирует на него, может быть моим единственным выбором, и я продолжу эксперименты. Но это может стать странным для локальных пользователей, которые используют $serviceaccount.
- ограничить вход с определенных IP-адресов (других серверов, использующих учетную запись службы)
Пользователи могли бы просто получить там оболочку и подключиться напрямую к интерактивной оболочке по протоколу ssh.
В заключение
Меня интересуют любые попытки достичь целей, описанных выше: платные решения, бесплатные решения, хакерские сценарии оболочки, настройка конфигурации ssh, настраиваемые оболочки по умолчанию, сценарии-оболочки и т. д. Я был бы рад увидеть даже частичные ответы. , и я могу добавить недостающие фрагменты.
Как разрешить пользователю входить в систему с помощью " su - user", но запретить пользователю входить в систему с помощью SSH?
Я попытался установить для оболочки значение /bin/false, но когда я пытаюсь выполнить команду su, это не работает.
Есть ли несколько способов разрешить вход только по su ?
Подойдет ли SSH AllowUser? (как бы я это сделал, если бы это было правильно)
11 ответов 11
Вы можете использовать AllowUsers / AllowGroups, если у вас есть только несколько пользователей/групп, которым разрешен вход через ssh или DenyUsers / < em>DenyGroups, если у вас есть только несколько пользователей/групп, которым не разрешен вход в систему. Обратите внимание, что это ограничивает вход только через ssh, другие способы входа (консоль, ftp, . ) все еще возможны. Вам необходимо добавить эти параметры в файл /etc/ssh/sshd_config для большинства установок ssh.
Если вы установили оболочку входа в систему /bin/false, вы можете использовать su -s /bin/bash пользователя (замените /bin/bash оболочкой на ваш выбор)
Большое спасибо всем.Я не ожидал, что мой вопрос получит более двух голосов :) Мне очень нравится конструкция "su -s . ", и консоль/ftp - хороший момент. Мне действительно нужно было что-то вроде "su -s".
Трюк с su -s — золото. Я использую его все время для системных учетных записей, мне нужно проверить разрешения, например, для apache, none и т. д. Обычно я делаю su - user -s /bin/bash. Необязательный аргумент - может использоваться для предоставления среды, похожей на то, что пользователь ожидал бы, если бы пользователь вошел в систему напрямую.
Если вам нужно загрузить переменные окружения (например, из /etc/profile), это можно сделать с помощью дополнительного дефиса: su - -s /bin/bash user
Если вы все еще хотите, чтобы su работал, вы можете использовать sudo -u [имя пользователя] или передать -s /bin/bash для su в качестве временной оболочки. Они оба делают то же самое, если в /etc/passwd отсутствует оболочка.
Если у учетной записи нет пароля (passwd -d имя пользователя), они не могут войти в систему интерактивно (через консоль, SSH и т. д.). Если у них есть допустимая оболочка, su все равно будет работать. Обратите внимание на «интерактивно»; если кто-то решит настроить пару ключей SSH для учетной записи, это сработает!
Нужно ли пользователю иметь действующую оболочку для su? Я почти уверен, что вы все еще находитесь в той же исходной оболочке после того, как вы отправили su другому пользователю. на самом деле вы не входите в систему как другой пользователь. Так что можно просто установить для оболочки значение /dev/null.
В sshd_config добавьте строку DenyUser [имя пользователя]
Обратите внимание, что это не помешает этому пользователю войти в систему через консоль.
В дополнение к тому, что было упомянуто выше (отключить и/или не устанавливать пароль пользователя), модуль pam_access (посмотрите справочную страницу pam_access и access.conf) может использоваться для управления доступом для входа в систему.
как говорили другие;
Имя пользователя DenyUser или имя группы DenyGroup в sshd_config не позволит войти в систему с помощью пары ключей/пароля через ssh.
хотя я обычно делаю что-то вроде AllowGroup ssh или что-то в этом роде и явно добавляю людей, которым нужен доступ ssh, в эту группу.
тогда вы можете сделать, как сказали другие: passwd -d имя пользователя, чтобы скрыть пароль пользователя, чтобы они не могли войти в консоль, или каким-либо другим способом. или еще лучше passwd -l имя пользователя, чтобы «заблокировать» учетную запись. возможно, ssh откажет в доступе к заблокированной учетной записи, даже с ключами, но я не уверен.
Читайте также: