Отключить пользовательскую оболочку по соображениям безопасности


58

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

Как мы можем заблокировать эти учетные записи пользователей, чтобы эти «пользователи» не имели оболочки и не могли войти? Мы хотим предотвратить возможность того, что кто-то может использовать SSH в качестве одной из этих учетных записей пользователей.

Ответы:


63

Вы можете использовать usermodкоманду для изменения оболочки входа пользователя.

usermod -s /sbin/nologin myuser

или же

usermod -s /usr/sbin/nologin myuser

Если ваша ОС не предоставляет / sbin / nologin, вы можете установить оболочку для команды NOOP, например / bin / false:

usermod -s /bin/false myuser

1
/bin/falseкажется более распространенным, чем /bin/true.
jw013

@ jw013 Я обновляю свой ответ, но оба должны работать нормально.
Иордания

1
Обратите внимание, что на Debian, на nologinсамом деле можно найти на/usr/sbin/nologin
xebeche

это была моя первая идея, к сожалению, «правильное» использование некоторых учетных записей пользователей отключено при настройкеnologin
Javier

2
@ JW013 На самом деле у меня есть, /usr/local/bin/maybeкоторый /dev/urandomвыбирает между этими двумя. Возможно я должен использовать это: D
hegez

21

Изменение оболочки входа не обязательно препятствует аутентификации пользователей (за исключением некоторых служб, которые проверяют, упоминается ли оболочка пользователя /etc/shells).

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

Изменение оболочки на /bin/falseили /usr/sbin/nologinзапретит им запускать команды только в тех службах, которые можно использовать для запуска команд (вход в консоль, ssh, telnet, rlogin, rexec ...), поэтому влияет на авторизацию только для некоторых служб.

Для ssh, например, что по- прежнему позволяет им делать перенаправление портов.

passwd -lотключит аутентификацию по паролю, но пользователю все равно может быть разрешено использовать другие методы аутентификации (например, authorized_keysс ssh).

По pamкрайней мере, в Linux вы можете использовать pam_shellsмодуль для ограничения аутентификации или авторизации для пользователей с разрешенной оболочкой (упомянутой в /etc/shells). Для ssh, вы хотите сделать это при авторизации ( account) уровня , как для аутентификации sshdиспользования pam в дополнение к другим методам аутентификации (как authorized_keys), или вы можете сделать это с sshd_configдирективами /etc/ssh/sshd_config(как AllowUsersи друзей).

Однако следует помнить, что добавление некоторых ограничений в глобальную авторизацию pam может помешать запуску cronзаданий от имени этих пользователей.


Спасибо. Тогда что бы вы порекомендовали, учитывая следующую схему: Мне нужно создать пользователя, которому нужен доступ к его домашней папке через sftp или sshfs, но он не должен иметь возможность войти в систему с оболочкой. Это вообще возможно? Я упал, как модули PAM, может быть решением goto, но я не понимаю всего этого:|
Stphane

@Stphane, вы можете взглянуть на rssh - manpages.ubuntu.com/manpages/trusty/man1/rssh.1.html
Харт Симха

4

Вы редактируете /etc/passwdфайл и меняете оболочку пользователя с /bin/bashили /bin/shна/sbin/nologin


8
Ответ правильный, но никогда не следует рекомендовать ручное редактирование / etc / passwd.
Иордания

3
Почему? Это то, чем мы занимаемся до тех пор, пока я являюсь профессиональным системным администратором. (около 20 лет) На самом деле, не во всех дистрибутивах Linux / Unix есть инструменты для изменения / etc / passwd или / etc / group. Если вы не используете что-то вроде Yast или Smit, которые являются инструментами, которые кэшируют настройки и перезаписывают им нет никакого вреда при ручном редактировании.
Марк Коэн

6
Гораздо проще сделать ошибку «нарушает вход в систему для всех» путем ручного редактирования, а не одним пользователем.
Иордания

2
@jordanm: есть, vipwчто предотвращает такую ​​ошибку.
eudoxos

4

Сначала отключите пароль, используя passwd -l username.

Также обратите внимание на manстранице passwdдля варианта -l:

   -l, --lock
       Lock the password of the named account. This option disables a password by changing it to a value which matches no
       possible encrypted value (it adds a ´!´ at the beginning of the password).

       Note that this does not disable the account. The user may still be able to login using another authentication token
       (e.g. an SSH key). To disable the account, administrators should use usermod --expiredate 1 (this set the account's
       expire date to Jan 2, 1970).

       Users with a locked password are not allowed to change their password.

1
Это может быть нежелательно. Например, для доступа к электронной почте им может понадобиться пароль в системной учетной записи.
Иордания

1
Некоторые почтовые системы позволяют использовать свои собственные механизмы паролей. Я использую Dovecot и Exim с паролем только для электронной почты. Это позволяет использовать веб-почту на серверах. Я бы не использовал свой системный пароль. Виртуальные почтовые домены требуют свой собственный пароль, поскольку они не связаны с системой паролей серверов.
BillThor

2

Вы можете использовать команду chsh:

~# chsh myuser

Введите новые данные оболочки при запросе:

Login Shell [/bin/sh]: /bin/nologin

Или более короткая версия:

~# chsh myuser -s /bin/nologin

0

Чтобы запретить пользователю входить в систему и даже проходить аутентификацию через ssh, который включает переадресацию портов (как описано здесь, Стефан), я изменяю пользователя так, чтобы он был похож на nobodyпользователя системы :

  • заблокирована аутентификация пароля в /etc/shadow*или !!в соответствующем поле)
  • отключена оболочка /etc/passwd(например, /sbin/nologinв соответствующем поле)
  • Домашний каталог только для чтения /etc/passwd(например, /в соответствующем поле)
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.