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

Обновлено: 07.07.2024

Linux - начинающим. Часть 6. Управление пользователями и группами. Теория

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

Чтобы понять современную систему пользователей в Linux сделаем небольшой экскурс в историю. Как известно, Линус Торвальдс создавал ОС по образу и подобию UNIX и поэтому в основе Linux лежат многие простые и изящные решения этой системы. Одна из замечательных абстракций UNIX - это все есть файл, т.е. файлами также являются устройства, процессы, сетевые сокеты и т.д. и т.п. Это позволяет делать при помощи достаточно простых инструментов довольно сложные вещи, например, чтобы сделать образ диска достаточно просто скопировать файл блочного устройства в файл образа, а для работы с последовательным портом достаточно прочитать или записать что-либо в файл устройства ввода-вывода.

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

Таким образом пользователи и группы определяют доступ не только к файлам в привычном нам понимании, но и ко всему спектру объектов операционной системы: процессам, устройствам, сокетам. Просто запомните, что все есть файл, а каждый файл имеет владельца и группу.

Условно всех пользователей можно разделить на специальных, служебных и обычных, но повторимся еще раз - деление это условное, все различие между ними заключается в предоставляемых им правах и некоторых иных возможностях. Чтобы получить список пользователей системы откроем файл /etc/passwd:

linux-user-and-group-management-001.jpg

Давайте рассмотрим его структуру подробнее. Каждая строка соответствует одному пользователю и имеет следующий формат:

С именем пользователя все понятно, а вот второй параметр может вызвать некоторое недоумение. Когда-то давно пароли хранились в открытом виде, о чем намекает само название файла, но затем от этой практики отказались и современные системы не хранят пароли в каком-либо виде вообще, хранится только сформированный по специальному алгоритму хеш, такие пароли в Linux называются затененными ( shadow). Для такого пароля во втором поле всегда ставится символ x.

UID (User identifier) и GID (Group identifier) - числовые идентификаторы пользователя и группы. Важно понимать, что система различает пользователей именно по UID, а не по наименованиям и многие системы имеют возможность создать несколько пользователей с одинаковым UID, с точки зрения системы это будет один и тот же пользователь.

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

В реальных сценариях данную возможность использовать не следует, так как наличие таких пользователей может вызвать конфликты в системе. Например, Gnome 3 в Debian 10 просто отказался загружаться после того, как мы создали такого пользователя.

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

Следующие два поля указывают на домашнюю директорию пользователя и его командную оболочку. Разным пользователям можно назначить разные командные оболочки, скажем, ваш коллега предпочитает zsh, то вы можете без проблем назначить ему любимую оболочку.

Рассмотрение командных оболочек Linux выходит за рамки данной статьи, поэтому мы оставим эту тему, но расскажем о двух специализированных "оболочках", которые указывают, когда пользователю запрещен интерактивный вход в систему. Это обычно применяется для служб и пользователей от имени которых исполняются некоторые скрипты. Даже если такая учетная запись будет скомпрометирована войти в консоль с ней не удастся.

Обычно для этой цели используется:

В современных системах директория /sbin является символической ссылкой на /usr/sbin. Реже используется "оболочка":

linux-user-and-group-management-002.jpg

Как мы уже говорили выше, всех пользователей можно условно разделить на три группы. К специальным пользователям относятся root (суперпользователь) и nobody (с группами root и nogroup). Это практически полные противоположности, root имеет наименьшие UID и GID - 0 и является обладателем неограниченных прав, он имеет доступ к любому объекту системы и может выполнять любые настройки. В отличие от Администратора Windows, который максимально огражден от деструктивных действий, root может с легкостью уничтожить систему.

Мы думаем, что следующая команда известна каждому, а некоторым - печально известна:

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

Современные дистрибутивы по умолчанию блокируют выполнение явно деструктивных команд, но не запрещают их, все это выглядит как предупреждение: "так делать опасно, но если ты настаиваешь. "

linux-user-and-group-management-003.jpg

С учетом вышесказанного есть ряд сложившихся правил работы с этим пользователем. Во-первых, не следует выполнять из-под учетной записи суперпользователя повседневную работу. Для разовых действий используйте sudo, для административных работ допустимо временно повышать привилегии с последующим обязательным выходом. Во-вторых, доступ к данной учетной записи должен быть тщательно ограничен, потому как утеря контроля над root равносильно полной потере контроля над системой.

Хорошая практика - сделать учетную запись root недоступной для интерактивного входа (как в Ubuntu) используя для повышения прав исключительно sudo, особенно это касается серверов с доступом к SSH из сети интернет.

Пользователь nobody (никто) - имеет наибольший идентификатор - 65534 и не может являться владельцем ни одного файла в системе, не состоит ни в одной привилегированной группе и не имеет никаких полномочий кроме стандартных. Используется для запуска от его имени процессов с низким уровнем доверия, чтобы ограничить их доступ к системе в случае возможной компрометации. Фактически к nobody будут всегда применяться права для "остальных" и при стандартных наборах привилегий 644 на файлы и 755 на директории он будет иметь возможность исключительно чтения и просмотра содержимого каталогов. Для чувствительных конфигурационных файлов, ключей и сертификатов используются более ограниченные наборы прав 640 или 600, к таким файлам nobody доступа не имеет.

Следующая условная группа - системные пользователи, которые используются для запуска служб и доступа к устройствам, например, www-data для веб-сервера или systemd-network для управления сетью через systemd. Первоначально для них выделялись идентификаторы от 1 до 100, но в связи с большим количеством служб в современных системах этот диапазон расширен до 499 в RHEL и производных от него, и до 999 в системах основанных на Debian.

Существует соглашение, что этот диапазон идентификаторов используется только системными службами и в нем не должно быть обычных пользователей. Однако никто не мешает назначить службе UID выше 1000, а пользователю менее 999, но никаких последствий это иметь не будет и никак не скажется на привилегиях. Это разделение чисто условное и предназначено для повышения удобства администрирования. Встретив в незнакомой системе пользователя с UID до 999, вы будете с большой долей вероятности предполагать, что это служба.

Кроме того, для многих стандартных пользователей идентификаторы зарезервированы, так во всех Debian и основанных на нем дистрибутивах www-data имеет UID и GID - 33, а proxy - 13. Это удобно, скажем вместо:

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

Многое стороннее ПО, например, сервер 1С и сборки PostgresPro занимают ближайшие свободные идентификаторы с верхнего конца диапазона: 999, 998 и т.д.

Из всего изложенного выше вы должны понимать, что система определяет пользователей по идентификаторам, а не по именам, а присвоение идентификаторов регулируется определенными правилами, но никакие из них, кроме двух специальных (0 для root и 65534 для nobody), не дают каких-либо дополнительных прав или привилегий.

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

Посмотреть список групп можно в файле /etc/group

linux-user-and-group-management-004.jpg

Он имеет следующий формат:

Большая часть полей аналогична записям в файле /etc/passwd и мы не будем подробно останавливаться на них. Разберем последний параметр - пользователи группы. При создании пользователя в Linux, если не указано иное, ему автоматически создается основная группа с повторяющим имя названием. Такой пользователь в последнем поле не указывается. Это хорошо видно на скриншоте выше. Но мы можем создать и отдельную группу, которая первоначально не содержит пользователей, и она будет иметь точно такой же вид записи с пустым последним полем.

После того как мы добавим пользователей в группу они будут перечислены в последнем поле через запятую.

linux-user-and-group-management-005.jpg

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

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

Теперь о паролях, как мы уже говорили, современные системы не хранят пароли в открытом виде, а используют для этого хеши - односторонние криптографические функции, при вводе пароля система вычисляет его хеш и сравнивает с уже сохраненным, если хеши совпадают - то пароль введен верно. Такие пароли в Linux называются "затененными" и хранятся в отдельных файлах. Для пользователей это файл /etc/shadow:

linux-user-and-group-management-006.jpg

Синтаксис этого файла предусматривает девять полей, содержащих следующую информацию:

  • Имя пользователя
  • Хеш пароля, если поле содержит ! или *, это означает, что учётная запись заблокирована и этот пользователь не сможет войти в систему.
  • Дата последней смены пароля -- Количество дней, прошедших с 1 января 1970 г.
  • Число дней, которое должно пройти до смены пароля -- Минимальный срок (в днях), который должен пройти, прежде чем пользователь сможет сменить пароль.
  • Число дней, после которого необходимо сменить пароль -- Максимальный срок (в днях), по истечении которого необходимо сменить пароль.
  • Число дней до предупреждения о необходимости смены пароля -- Число дней до истечения срока действия пароля, в течение которых пользователь получает предупреждение об окончании его срока действия.
  • Число дней до отключения учётной записи -- Число дней после окончания срока действия пароля до отключения учётной записи.
  • Дата отключения учетной записи -- Количество дней, прошедших с 1 января 1970 г.
  • Зарезервированное поле

Наибольший интерес представляет второе поле, содержащее хеш пароля, оно имеет структуру:

Где ID - применяемый тип шифрования, могут использоваться следующие значения:

  • $1 - MD5, самый слабый хеш, в настоящее время не используется
  • $2 - Blowfish, использовался в BSD-системах
  • $5 - SHA-256
  • $6 - SHA-512

В современных системах используется наиболее стойкий хеш SHA-512.

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

Соль позволяет исключить атаки при помощи заранее вычисленных значений и при ее случайном значении позволяет скрыть наличие у пользователей одинаковых паролей. На скриншоте выше пользователям ivan и maria были установлены одинаковые пароли, но за счет различной соли они имеют различный хеш.

Ну и наконец ENCRYPTED - это, собственно, хеш. Кроме того, данное поле может содержать спецсимволы: *, ! и !!. Все они обозначают, что учетная запись заблокирована для входа с паролем, но не запрещают иные варианты входа (по SSH-ключу). Символ * обычно используется для системных учетных записей, которым вход в систему запрещен, ! ставится для записей пользователей без пароля или заблокированных администратором (тогда ! ставится перед содержимым поля). Иногда используется символ !!, означающий что данной учетной записи никогда не присваивался пароль (также для такой записи может использоваться просто !).

Для групп используется аналогичный по назначению файл /etc/gshadow

linux-user-and-group-management-007.jpg

Его структура более проста, а поля имеют следующее назначение:

  • Имя группы
  • Хеш пароля, если пароль установлен, не члены группы могут войти в нее, выполнив команду newgrp и указав пароль. Если это поле содержит * или !, ни один пользователь не сможет войти в неё указав пароль.
  • Администраторы группы -- Перечисленные здесь (через запятую) члены группы могут добавлять или удалять членов группы с помощью команды gpasswd.
  • Члены группы -- Здесь перечисляются (через запятую) обычные члены группы, не администраторы.

Поле пароля также может содержать спецсимволы и также как для пользователей символ * используется преимущественно для системных групп, а ! для групп пользователей. По умолчанию пароли групп отсутствуют и вход в них заблокирован, т.е. никто, кроме членов группы, не может войти в группу, а членам пароль не нужен.

Файлы shadow и gshadow содержат важную учетную информацию и должны быть хорошо защищены. Владельцами этих файлов является root:shadow и права доступа для них установлены как 640. Это означает, что вносить изменения в них может только владелец - root, а читать только члены специальной группы shadow. Это дополнительный уровень безопасности, позволяющий исключить доступ к этим файлам добавлением пользователя в группу root (что даст доступ на чтение к другим конфигурационным файлам).

linux-user-and-group-management-008.jpg

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

Поэтому даже если что-то пойдет не так, всегда есть возможность (при условии физического доступа к системе) восстановить состояние этих файлов на момент перед внесением изменений в конфигурацию. В качестве примера приведем следующую ситуацию: вы случайно удалили единственного пользователя с административными правами из группы sudo, root при этом заблокирован, после завершения сеанса в системе не останется ни одного привилегированного пользователя.

Как вы разрешаете пользователю входить в систему, используя « 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 на выбранную вами оболочку)

Большое спасибо всем. Я не ожидал получить более 2 голосов по моему вопросу :) Мне очень нравится конструкция "su -s . ", и консоль / ftp - хороший момент. Я был действительно после чего-то вроде "Су-с". Уловка su-s - золото. Я использую его все время для системных учетных записей, для которых мне нужно проверить права доступа, например, для apache, nobody и т. Д. Я обычно делаю su - user -s / bin / bash. Необязательный аргумент - может использоваться для предоставления среды, аналогичной той, которую пользователь ожидал бы при непосредственном входе пользователя в систему. Если вам нужны переменные окружения (например , из / и т.д. / профиль) , который будет загружен, проходя дополнительный тире будет делать это: su - -s /bin/bash user

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

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

пользователь должен иметь действительную оболочку для su? Я почти уверен, что вы все еще находитесь в той же оригинальной оболочке после того, как вы su для другого пользователя . на самом деле вы НЕ ВХОДИТЕ в систему как другой пользователь . Итак, просто установка оболочки на / dev / null может работать также. Да, ему все еще нужна корректная оболочка: [root @ localhost

В 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 запретит доступ к заблокированной учетной записи, даже с ключами, но я не уверен.

На самом деле ssh позволит вам войти с использованием аутентификации по ключу, даже если пароль учетной записи заблокирован.

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

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

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

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

Основная часть системного администрирования – конфигурирование и управление пользователями и группами. Эта задача включает в себя мониторинг возможностей получения доступа в систему всех ее подразделений.

Данное руководство описывает основные понятия об управлении пользователями и регистрации их авторизации.

Эти понятия изучаются на 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», изменяющий легитимное значение оболочки фиктивным:

sudo usermod -s /usr/sbin/nologin username

Как ограничить вход с помощью /etc/shadow

Другой подобный способ ограничения доступа – использование файла «/etc/shadow». Данный файл содержит хешированные пароли каждого пользователя системы.

Чтобы просмотреть хешированные пароли, введите:

sudo less /etc/shadow
root:$6$r79Dod3Y$3hi3QklpGEQMxwQGEss4ueNNPkoUrqUe3SwyAacaxl.Lmgq1r9i4mTblV1z6NfKMNXH1Cpnq.4iKhOiQd7Riy1:15953:0:99999:7.
daemon:*:15455:0:99999:7.
bin:*:15455:0:99999:7.
sys:*:15455:0:99999:7.
sync:*:15455:0:99999:7.
games:*:15455:0:99999:7.
man:*:15455:0:99999:7.
. . .

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

Значение пароля можно деактивировать (сделав его, по сути равным значению «*»), установив перед хешированным значением восклицательный знак (!).

Два инструмента могут заблокировать указанную учетную запись.

Команда passwd может быть заблокирована с помощью флага «-l» и разблокирована флагом «-u»:

sudo passwd -l username
sudo less /etc/shadow | grep username
username:!$6$vpNJ3oFe$5GSh2aU2BDcpdjvQeNFzh0zTgyRUl26x4dn77mFE/vaoXwd19m7okX44jO8TWaVqNRL8vUVTAcZVmgUT8dR.4.:15953:0:99999:7.

Как видно, хешированный пароль сохранился, но стал недействительным благодаря символу ! перед ним.

Учетная запись может быть разблокирована при помощи:

sudo passwd -u username

Подобные операции можно выполнить при помощи команды «usermod», которая использует флаги «-L» и «-U» для блокировки и разблокировки соответственно.

sudo usermod -L username
sudo usermod -U username

Примечание: данные методы могут заблокировать доступ только учетным записям на основе пароля, пользователи без пароля (к примеру, ssh-ключи) по-прежнему могут войти в систему.Рассмотрите возможность использования других методов блокировки таких учетных записей.

Как ограничить вход с помощью /etc/nologin

В экстренных ситуациях бывает необходимо запретить вход всем аккаунтам, кроме root.

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

В любом случае, это легко сделать, создав файл «/etc/nologin»:

sudo touch /etc/nologin

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

Пустой файл просто сбрасывает пользователей обратно в локальную оболочку без объяснения причин.

sudo sh -c 'echo "Planned maintenance. Log in capabilities will be restored at 1545 UTC" > /etc/nologin'

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 – достаточно гибкая область управления системой, так как одни и те же задания можно выполнить при помощи различных простых инструментов.

Как обычная практика, пользователи обязаны обеспечивать информацию аутентификации для вхождения в систему Linux. Это помогает в обеспечении любых чувствительных или персональных файлов, электронных писем и других данных, находящихся в Вашей системе от любого физического проникновения. Однако, если Ваша система уже помещается в безопасное место, лишенное угрозы конфиденциальности, можно избежать стычки обеспечения удостоверений пользователя каждый раз, когда Вы входите в систему. Эта статья предоставляет Вам следующие два способа позволить/запретить автоматический вход в систему Вашей системы Ubuntu:

  • Через командную строку.
  • Через графический интерфейс.

Обратите внимание на то, что мы выполняем это учебное руководство на Ubuntu 18.04 LTS (Бионический Бобр) система.

Как суперпользователь, можно включить автоматический вход в систему для себя или для любого другого пользователя Ubuntu путем создания некоторых изменений конфигурации в custom.conf файле следующим образом:

  1. Откройте Terminal through Ubuntu Dash или путем нажатия Ctrl+Alt+T.
  2. Откройте custom.conf файл в редакторе Nano посредством следующей команды:

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

При вводе пароля следующий файл откроется:


Включите автоматический вход в систему для пользователя


В этом учебном руководстве мы заменили значение user1 sana. Вы видите изменение в цвете теперь активированной опции.

Теперь сохраните файл путем нажатия Ctrl+X и затем Y.

Отключите автоматический вход в систему для пользователя


Вы видите изменение в цвете теперь отключенной опции. Сохраните файл путем нажатия Ctrl+X и затем Y. Теперь, когда Вы перезапускаете компьютер, указанного пользователя попросят предоставить подробную информацию аутентификации для входа в систему.

Можно позволить/запретить автоматический вход в систему для себя или для любого другого пользователя Ubuntu через графический интерфейс следующим образом:

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


Выберите опцию Account Settings.

Следующее Пользовательское диалоговое окно откроется. Так как необходимо быть суперпользователем для конфигурирования этих настроек, кнопка Automatic Login будет отключена по умолчанию. Нажмите на кнопку Unlock, расположенную в верхней правой стороне диалогового окна для включения этой кнопки.


Предоставьте подробную информацию аутентификации через следующее диалоговое окно и нажмите Authenticate:


Можно теперь переключить кнопку Automatic Login на ПРОЧЬ или НА в зависимости от того, хотите ли Вы включить или отключить автоматическую запись пользователя в.


При перезапуске компьютера процедура аутентификации входа в систему будет зависеть от выбора, который Вы сделали здесь.

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


Мануал

Учетная запись root является конечной учетной записью в Linux и других Unix-подобных операционных системах.

Эта учетная запись имеет доступ ко всем командам и файлам в системе с полными разрешениями на чтение, запись и выполнение.

Она используется для выполнения любой задачи в системе; создавать / обновлять / получать доступ / удалять учетные записи других пользователей, устанавливать / удалять / обновлять пакеты программного обеспечения и многое другое.

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

В этом отношении любые ошибки пользователя root могут иметь серьезные последствия для нормальной работы системы.

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

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

В этой статье мы объясним четыре способа отключения учетной записи пользователя root в Linux.

Внимание. Прежде чем блокировать доступ к учетной записи root, убедитесь, что вы создали админскую учетную запись, способную использовать команду sudo для получения привилегий пользователя root, с помощью команды useradd и предоставить этой учетной записи надежный пароль. Флаг -m означает создание домашнего каталога пользователя, а -c позволяет указать комментарий:

Затем добавьте этого пользователя в соответствующую группу системных администраторов, используя команду usermod, где ключ -a означает добавление учетной записи пользователя, а -G указывает группу для добавления пользователя в (колесо или sudo в зависимости от вашего дистрибутива Linux):

После того, как вы создали пользователя с правами администратора, переключитесь на эту учетную запись, чтобы заблокировать доступ root.

1. Изменение оболочки пользователя root

Сохраните файл и закройте его.

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

2. Отключить root через консольное устройство (TTY)

Второй метод использует модуль PAM, называемый pam_securetty, который разрешает root-доступ только в том случае, если пользователь регистрируется в «защищенном» TTY, как определено в списке в /etc/securetty.

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

Чтобы создать пустой файл, запустите

Этот метод имеет некоторые ограничения, он влияет только на такие программы, как логин, диспетчеры отображения (например, gdm, kdm и xdm) и другие сетевые службы, запускающие TTY.

Такие программы, как su, sudo, ssh и другие связанные с ними средства openssh, будут иметь доступ к учетной записи root.

3. Отключить вход root по SSH

Затем раскомментируйте (если она закомментирован) директиву PermitRootLogin и установите ее значение равным no, как показано на скриншоте.

Как только вы закончите, сохраните и закройте файл.

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

Как вы уже знаете, этот метод влияет только на набор инструментов openssh, такие программы, как ssh, scp, sftp, будут заблокированы для доступа к учетной записи root.

4. Ограничение доступа root к службам через PAM

PAM через модуль /lib/security/pam_listfile.so обеспечивает большую гибкость в ограничении привилегий конкретных учетных записей.

Вышеупомянутый модуль может использоваться для ссылки на список пользователей, которым не разрешено входить в систему через некоторые целевые службы, такие как login, ssh и любые программы, поддерживающие PAM.

В этом случае мы собираемся отключить доступ пользователя root к системе, ограничив доступ к входам и службам sshd.

Сначала откройте и отредактируйте файл для целевой службы в каталоге /etc/pam.d/, как показано ниже:

Затем добавьте конфигурацию ниже в оба файла.

Когда все будет готово, сохраните и закройте каждый файл. Затем создайте простой файл / etc / ssh / deniedusers, который должен содержать один элемент на строку, а не читаемый в мире.

Добавьте в него имя root, затем сохраните и закройте его.

Также установите необходимые разрешения для этого файла.

Этот метод влияет только на программы и службы, которые известны PAM.

Вы можете заблокировать доступ root к системе через ftp и почтовые клиенты и многое другое.

Для получения дополнительной информации обратитесь к соответствующим страницам руководства.

Читайте также: