Bin false что это
В чем разница между /sbin /nologin и /bin /false?
Я вижу на странице man, что /sbin/nologin печатает сообщение пользователю, говоря, что учетная запись отключена, а затем завершает работу. Предположительно /bin/false ничего не печатает.
3 ответа
POSIX (хотя я могу ошибаться, и это может быть SUS) ограничивает обе эти команды только тем, что возвращает только соответствующее логическое значение.
В любом случае scp не будет работать с недопустимой оболочкой. scponly может использоваться как оболочка в этом экземпляре.
После некоторых исследований по этому методу используемый вами метод зависит от того, что вам нужно заблокировать. Если пользователь входит в систему с этим набором в оболочку, тогда они получат сообщение, отображаемое с эффектом This account is currently unavailable. Обратите внимание, что вы можете изменить это, создав файл /etc/nologin.txt по крайней мере на производных RHEL.
Как вы знаете, /bin/false не является оболочкой. Как он работает, так это то, что он возвращает false, который выходит из системы сразу после двоичных выходов. Обратите внимание, что /bin/true достигнет того же эффекта.
Поэтому /bin/false или /bin/true лучше всего запретить пользователю входить в любую службу, а /sbin/nologin будет по-прежнему позволять пользователям входить в сервисы, отличные от SSH или локальной консоли, обеспечивая при этом обратную связь с пользователем, что учетная запись неактивна, и ее лучше всего использовать, когда нужно заблокировать только SSH /локальную консоль.
Um, попросил ли кто-нибудь попробовать доказать, что /bin /false запретит доступ к FTP?
Я только что изменил оболочку моего пользователя на /bin /false и смог полностью FTP.
Я использую /dev /null для полностью блокирует пользователя (ну, кроме электронной почты, они могут по-прежнему POP3).
Доступ пользователей в vsftpd без доступа к shell (/bin/false)
Для обеспечения большей безопасности FTP-сервера VSFTPD (как установить можно почитать тут), запретим пользователям доступ к Shell (/bin/false).
Создание нового пользователя без доступа к Shell (/bin/false):
Где:
username — имя пользователя.
ключ -b — Директория где будет находиться его домашний каталог
ключ -m — Создание домашнего каталога одноименного с названием username.
ключ -s /bin/false — Указываем что пользователю будет отключен Shell
Задаем пароль для созданного пользователя:
Если необходимо отключить Shell уже существующему пользователю, то открываем файл /etc/passwd:
Находим нужного пользователя и меняем /bin/bash на /bin/false. Сохраняем изменения и при следующей авторизации пользователя на FTP будут без доступа к Shell.
По-умолчанию VSFTPD настроен так что доступ к FTP могут получить пользователи у которых включен Shell (т.е. /bin/bash), а пользователи у которых отключен Shell (т.е. /bin/fasle) VSFTPD не смогут авторизоваться на FTP-сервере.
Способы ограничения возможности входа пользователей в Ubuntu
Вступление
Основная часть системного администрирования – конфигурирование и управление пользователями и группами. Эта задача включает в себя мониторинг возможностей получения доступа в систему всех ее подразделений.
Данное руководство описывает основные понятия об управлении пользователями и регистрации их авторизации.
Эти понятия изучаются на Ubuntu 12.04 VPS, но данные действия можно выполнить на любом современном дистрибутиве Linux.
Как известно, некоторые из пользователей сервера могут быть связаны с сервисами, а потому они не предназначены для использования в качестве обычных учетных записей.
Данное руководство рассматривает несколько способов ограничения возможности входа в систему таких пользователей.
Как ограничить доступ с помощью /etc/passwd
Один из способов ограничения возможности входа – это задать регистрационной оболочке учетной записи специальное значение.
Примером этому является пользователь «messagebus» в файле «/etc/passwd»:
less /etc/passwd | grep messagebus
messagebus:x:102:104::/var/run/dbus:/bin/false
последнее значение – это оболочка или команда, которая запускается в случае успешного входа. Сейчас это «/bin/false».
Если войти в учетную запись messagebus как root-пользователь, ничего не произойдет, так как переключиться на этого пользователя не получится:
sudo su messagebus
Попробуйте переключиться на пользователя sshd:
sudo su sshd
This account is currently not available.
Это уведомление появилось потому, что оболочка пользователя sshd помещена в «/usr/sbin/nologin».
less /etc/passwd | grep sshd
sshd:x:103:65534::/var/run/sshd:/usr/sbin/nologin
Итак, как же ограничить вход пользователей с помощью этих методов?
Нужно использовать инструмент «usermod», изменяющий легитимное значение оболочки фиктивным:
Как ограничить вход с помощью /etc/shadow
Другой подобный способ ограничения доступа – использование файла «/etc/shadow». Данный файл содержит хешированные пароли каждого пользователя системы.
Чтобы просмотреть хешированные пароли, введите:
Второе поле (которое начинается с «$6$r79Dod3Y#3…» в первой строке) содержит хешированное значение пароля.
Как можно видеть, учетные записи системы вместо сложного хешированного значения имеют звездочку (*). Учетным записям со звездочкой во втором поле пароль не был установлен и они не могут пройти регистрацию при помощи пароля.
Значение пароля можно деактивировать (сделав его, по сути равным значению «*»), установив перед хешированным значением восклицательный знак (!).
Два инструмента могут заблокировать указанную учетную запись.
Команда passwd может быть заблокирована с помощью флага «-l» и разблокирована флагом «-u»:
Учетная запись может быть разблокирована при помощи:
Подобные операции можно выполнить при помощи команды «usermod», которая использует флаги «-L» и «-U» для блокировки и разблокировки соответственно.
Примечание: данные методы могут заблокировать доступ только учетным записям на основе пароля, пользователи без пароля (к примеру, ssh-ключи) по-прежнему могут войти в систему.Рассмотрите возможность использования других методов блокировки таких учетных записей.
Как ограничить вход с помощью /etc/nologin
В экстренных ситуациях бывает необходимо запретить вход всем аккаунтам, кроме root.
Это может случиться из-за углубленного технического обслуживания, или потому, что одна или несколько учетных записей были взломаны.
В любом случае, это легко сделать, создав файл «/etc/nologin»:
sudo touch /etc/nologin
Это действие блокирует вход любого пользователя, не имеющего привилегий root.
Пустой файл просто сбрасывает пользователей обратно в локальную оболочку без объяснения причин.
Дело в том, что пользователю просто возвращается содержимое файла. Если добавить в файл сообщение, то пользователи получат объяснение ошибки входа:
Попробуйте войти в систему с помощью пароля, тогда будет выведено установленное сообщение:
ssh user@host
user@host’s password:
Planned maintenance. Log in capabilities will be restored at 1545 UTC
Connection closed by host
Root-пользователь по-прежнему может войти в систему. Чтобы отменить ограничения входа, просто удалите файл «/etc/nologin»:
sudo rm /etc/nologin
Итоги
Идентификация пользователей в Linux – достаточно гибкая область управления системой, так как одни и те же задания можно выполнить при помощи различных простых инструментов.
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
У каждого файла обязательно есть владелец и группа, которой он принадлежит. На этой схеме строится классическая система прав в Linux и UNIX: владелец, группа и остальные. Более подробно о ней вы можете прочитать в предыдущих частях нашего цикла:
Таким образом пользователи и группы определяют доступ не только к файлам в привычном нам понимании, но и ко всему спектру объектов операционной системы: процессам, устройствам, сокетам. Просто запомните, что все есть файл, а каждый файл имеет владельца и группу.
Давайте рассмотрим его структуру подробнее. Каждая строка соответствует одному пользователю и имеет следующий формат:
С именем пользователя все понятно, а вот второй параметр может вызвать некоторое недоумение. Когда-то давно пароли хранились в открытом виде, о чем намекает само название файла, но затем от этой практики отказались и современные системы не хранят пароли в каком-либо виде вообще, хранится только сформированный по специальному алгоритму хеш, такие пароли в Linux называются затененными ( shadow). Для такого пароля во втором поле всегда ставится символ x.
Этим часто пользуются злоумышленники, один из типовых сценариев проникновения предусматривает создание пользователя с неприметным именем, но идентификаторами root, что позволяет действовать в системе от имени суперпользователя не привлекая ненужного внимания.
В реальных сценариях данную возможность использовать не следует, так как наличие таких пользователей может вызвать конфликты в системе. Например, Gnome 3 в Debian 10 просто отказался загружаться после того, как мы создали такого пользователя.
В поле комментарий можно написать все что угодно, определенного формата в современных системах нет, но исторически данное поле называется GECOS и подразумевает перечисление через запятую следующих опций:
Следующие два поля указывают на домашнюю директорию пользователя и его командную оболочку. Разным пользователям можно назначить разные командные оболочки, скажем, ваш коллега предпочитает zsh, то вы можете без проблем назначить ему любимую оболочку.
Рассмотрение командных оболочек Linux выходит за рамки данной статьи, поэтому мы оставим эту тему, но расскажем о двух специализированных «оболочках», которые указывают, когда пользователю запрещен интерактивный вход в систему. Это обычно применяется для служб и пользователей от имени которых исполняются некоторые скрипты. Даже если такая учетная запись будет скомпрометирована войти в консоль с ней не удастся.
Обычно для этой цели используется:
В современных системах директория /sbin является символической ссылкой на /usr/sbin. Реже используется «оболочка»:
Разница между ними заключается в том, что /bin/false просто запрещает вход в систему, а /sbin/nologin выдает сообщение:
Предупреждение! Данная команда уничтожает корневую файловую систему, что приводит к ее полной неработоспособности и потере всех данных. Приведена сугубо в качестве примера.
Современные дистрибутивы по умолчанию блокируют выполнение явно деструктивных команд, но не запрещают их, все это выглядит как предупреждение: «так делать опасно, но если ты настаиваешь. «
С учетом вышесказанного есть ряд сложившихся правил работы с этим пользователем. Во-первых, не следует выполнять из-под учетной записи суперпользователя повседневную работу. Для разовых действий используйте sudo, для административных работ допустимо временно повышать привилегии с последующим обязательным выходом. Во-вторых, доступ к данной учетной записи должен быть тщательно ограничен, потому как утеря контроля над root равносильно полной потере контроля над системой.
Существует соглашение, что этот диапазон идентификаторов используется только системными службами и в нем не должно быть обычных пользователей. Однако никто не мешает назначить службе UID выше 1000, а пользователю менее 999, но никаких последствий это иметь не будет и никак не скажется на привилегиях. Это разделение чисто условное и предназначено для повышения удобства администрирования. Встретив в незнакомой системе пользователя с UID до 999, вы будете с большой долей вероятности предполагать, что это служба.
Но это тоже условность, скажем в отсутствии установленного веб-сервера мы можем назначить «зарезервированный» UID другому пользователю без каких-либо последствий, веб-сервер при установке возьмет ближайший свободный UID, но такие действия безусловно являются дурным тоном.
Многое стороннее ПО, например, сервер 1С и сборки PostgresPro занимают ближайшие свободные идентификаторы с верхнего конца диапазона: 999, 998 и т.д.
Из всего изложенного выше вы должны понимать, что система определяет пользователей по идентификаторам, а не по именам, а присвоение идентификаторов регулируется определенными правилами, но никакие из них, кроме двух специальных (0 для root и 65534 для nobody), не дают каких-либо дополнительных прав или привилегий.
Для более гибкого управления пользователями предназначены группы, они позволяют объединять пользователей по любому произвольному принципу и назначать им дополнительные права. Если мы хотим разрешить пользователю повышение прав, то мы включаем его в группу sudo, при этом мы всегда можем легко узнать, кто именно обладает такой возможностью, достаточно посмотреть участников группы.
Посмотреть список групп можно в файле /etc/group
Он имеет следующий формат:
После того как мы добавим пользователей в группу они будут перечислены в последнем поле через запятую.
Давайте внимательно посмотрим на скриншот и проанализируем членство созданного при установке пользователя andrey в дополнительных группах. Практически все они связанны с доступом к оборудованию или дают возможность использовать некоторые системные механизмы, скажем группа plugdev предоставляет возможность монтировать съемные устройства.
В современных системах, при работе в графических средах доступ к оборудованию часто предоставляется механизмами рабочей среды, которые не используют разделение прав на основе членства пользователя в соответствующих группах. Поэтому, если вы используете стандартные механизмы дистрибутива, то для полноценного использования оборудования вам нет необходимости включать пользователя в дополнительные группы. Однако это может потребоваться при работе в консоли или при использовании нестандартных или специализированных устройств в графической среде.
Синтаксис этого файла предусматривает девять полей, содержащих следующую информацию:
Наибольший интерес представляет второе поле, содержащее хеш пароля, оно имеет структуру:
В современных системах используется наиболее стойкий хеш SHA-512.
Соль позволяет исключить атаки при помощи заранее вычисленных значений и при ее случайном значении позволяет скрыть наличие у пользователей одинаковых паролей. На скриншоте выше пользователям ivan и maria были установлены одинаковые пароли, но за счет различной соли они имеют различный хеш.
Для групп используется аналогичный по назначению файл /etc/gshadow
Его структура более проста, а поля имеют следующее назначение:
Поле пароля также может содержать спецсимволы и также как для пользователей символ * используется преимущественно для системных групп, а ! для групп пользователей. По умолчанию пароли групп отсутствуют и вход в них заблокирован, т.е. никто, кроме членов группы, не может войти в группу, а членам пароль не нужен.
Так как данные о пользователях являются критичными для системы, то указанные выше файлы крайне не рекомендуется изменять вручную, а для управления пользователями и группами следует использовать специальные утилиты, о которых мы поговорим в следующей части. При любом изменении информации в них штатными инструментами система создает резервную копию предыдущей версии файла с добавлением в конце имени символа
Поэтому даже если что-то пойдет не так, всегда есть возможность (при условии физического доступа к системе) восстановить состояние этих файлов на момент перед внесением изменений в конфигурацию. В качестве примера приведем следующую ситуацию: вы случайно удалили единственного пользователя с административными правами из группы sudo, root при этом заблокирован, после завершения сеанса в системе не останется ни одного привилегированного пользователя.
Дополнительные материалы:
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал:
В чем разница между / sbin / nologin и / bin / false
Технически, если pam настроен для проверки вашей оболочки с помощью pam_shells ни один из них не может фактически предотвратить ваш логин, если вы не находитесь в оболочке. В моей системе они даже разных размеров, поэтому я подозреваю, что они действительно что-то делают. Так в чем разница? почему они оба существуют? Почему я должен использовать один над другим?
nologin – это более удобный для пользователя вариант с настраиваемым сообщением пользователю, пытающемуся войти в систему, поэтому вы теоретически хотите его использовать; но и nologin и false будут иметь тот же конечный результат, когда кто-то не имеет оболочки и не сможет войти в ssh.
Некоторые FTP-серверы позволят вам получить доступ к FTP только в том случае, если у вас есть действующая оболочка. /sbin/nologin считается действительной оболочкой, тогда как /bin/false – нет.
/usr/sbin/nologin специально разработан, чтобы заменить оболочку и выдавать выходные жалобы, что вы не можете войти в систему. До того, как он существовал, было общепринято использовать /bin/false для фиктивных пользователей, но может сбивать с толку, так как пользователь не знает, почему их начали.
Удобство использования, nologin лучше, если он используется на счет реального человека, который говорит по-английски. С точки зрения безопасности, нет никакой разницы.
/ bin / false только для выхода с ненулевым кодом выхода.
Попробуйте в командной строке:
Некоторые учреждения используют / bin / false в поле оболочки файла паролей. Если пользователь пытается войти в систему, оболочка будет / bin / false, поэтому они сразу же выходят
Надеюсь, это поможет.
Они могут быть одной и той же программой, но они имеют разные значения. Название программы сообщает все.
Оба делают более или менее одну и ту же работу, но /bin/false полезны для не-привилегированных пользователей. С другой стороны, /sbin/nologin предназначен для привилегированных пользователей.