Таймаут ввода пароля linux

Проблемы при вводе пароля LUKS

Столкнулся со странной проблемой. Не получается ввести пароль от LUKS контейнера при загрузке. Судя по появляющимся звёздочкам половина символов просто проглатывается. Причём если подождать с минуту, то вводится нормально. Отсюда тег systemd, похоже на какую-то гонку юнитов. Монтирую var и home, initramfs пересобирал, Plymouth выключал. Клавиатура встроенная в ноут, рабочая. Гугл молчит, выручайте.

В общей цепочке загрузки (см ниже) initramfs работает до того как начинает работать любая система инициализации.

«Гонка юнитов» начнется после того как отработает в initramfs отработает switch_root и сменит корень с initramfs-а на реальный root.

Так что разбирайся со своими тараканами.

Не уловил мысль. Окей, лишний тег. У меня не корень в контейнере же.

У меня не корень в контейнере же.

Тогда я «не уловил» при чем здесь тогда LUKS и initramfs?

Что у тебя зашифровано? Куда монтируется LUKS?

Написано в посте. var и home. С отдельных разделов.

Написано в посте. var и home. С отдельных разделов.

Ок. var и home у тебя в LUKS. И судя по «гонке юнитов» и перехвату фокуса ввода монтируешь ты их вовсе не при помощи initramfs а при помощи systemd.

Если-бы ты монтировал var и home в initramfs оно бы тебя тупо спросило бы пасворд а в systemd да там в параллель понесется всё а как дойдет до LUKS начнет ждать от тебя пароля вперемешку выплёвывая разное на екран.

Повторяю внимательно разбирайся со своими тараканами.

Какими тараканами, ёбт? Сказать-то что хотел?

Он имеет в виду то, что если те юниты монтируются systemd, предсказать, что с ними будет, уже нельзя. Хочешь предсказуемой работы декрипта — раскриптовывай еще в стадии initramfs.

Со своими тараканами «ёбт»!

предсказать, что с ними будет, уже нельзя

И да anonymous в этой фразе прав поскольку у systemd юниты в параллель и в тот момент пока один юнит ждет от тебя пароль другие будут срать своим выхлопом в ту же консоль. А в сумме ты будешь иметь то что и имеешь.

С любовью. Всегда твой Капитан.

LUKS-контейнер разблокируется в initramfs или после него? Если первое, то initramfs на скриптах или на systemd? Приведи fstab/crypttab/kernel cmdline/mkinitcpio.conf.

LUKS-контейнер разблокируется в initramfs или после него?

Под конец первой страницы выяснили что LUKS у него разблокирует не initramfs а systemd.

Ой, я тред не прочитал.А, всё равно в треде ничего полезного, один срач. Если что в арче в initramfs тоже может быть systemd.

В initramfs, который генерирует dracut, в качестве init тоже может быть systemd, с юнитами и прочим.

Кстати, если кто объяснит практическую разницу между обычными хуками и systemd’шными буду очень благодарен.

Т. е. у тебя не LVM-on-LUKS, а отдельно закриптованы два GPT-раздела? Сейчас попробую воспроизвести.

Элементарно: внутри initramfs у тебя может быть как «классический» скрипт запуска, написанный полностью вручную, так и экземпляр systemd. Это зависит от того, включен ли у тебя хук systemd.

Дальше, хуки бывают двух видов: такие, которые просто добавляют в initramfs какие-то файлы (например, модули ядра), и такие, которые добавляют в initramfs новую логику, т. е. «дописывают» в главный скрипт запуска какие-то куски кода. Очевидно, хуки второго типа несовместимы с systemd, т. к. в этом случае в initramfs просто нет никакого «главного скрипта». Соответственно, то, что ты видишь — это их варианты, переделанные под systemd.

Спасибо. Это я более-менее понимаю. Вопрос скорее в том, какой мне как пользователю профит (или наоборот) от «новых» хуков?

Не, LVM вообще нет. Хочется доступ к музыке из под оффтопика иметь.

Пользователю от systemd (и всего, что с ним связано) профита нет никакого от слова совсем.

В initramfs, который генерирует dracut, в качестве init тоже может быть systemd, с юнитами и прочим.

И что? В «initramfs, который генерирует dracut» с systemd в роли init тоже 100500 юнитов которые перебивая друг-друга мешают ТС ввести его пароль для LUKS-а?

Ну фиг знает. Человеческое логирование — уже профит огого.

Как минимум там есть юниты для работы с блочными устройствами, в т.ч. LUKS, LVM, всякие триггеры udev и автогенерируемые юниты systemd, которые могут активироваться после появления того или иного устройства.

Я не говорю, что в этом 100% проблема, но и не откидывал бы такую возможность. Впрочем, изучить initramfs можно с помощью отладочного шелла, и посмотреть, что там наделал systemd.

Ой лол. Plymouth был виноват. Отключал его, но почему-то увидел ложно отрицательный результат. Всем спасибо.

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

Забавно. А я так и не успел у себя настроить LUKS, чтобы воспроизвести.

А что, Plymouth не регистрируется в systemd’шном ask-password как агент?

Источник

Не могу зайти в юзера. Бесконечно просит ввести пароль. [Решено]

На Линуксе недавно.

Проблема такая:
Не могу войти в юзера после последней перегрузки. Ввожу пароль(все правильно %100), экран на секунду гаснет и опять просит ввести пароль.

У меня стоит Linux 38.0-35-generic
Версия набора по KDE 4.10.5

Вот что я уже пытался сделать:
1. Удалял пароль.
Зашел под рутом # passwd (ник) -d
2.Удалил файлы Xauthoruty и ICEauthority:
cd

/; rm -f .Xauthority .ICEauthority
sudo shutdown -r now

Не помогло. Сюда буду писать дальнейшие свои действия и очень благодарен вашим советам, уважаемые форумчане! 🙂

попробуй загрузиться с live cd и подключить корневой раздел и это

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

1.сначала сбросишь, потом можно поставить новый;
2.например, у меня это будет выглядеть так sudo mount /dev/sda8 /mnt , где sda8 раздел, на котором установлен Linux (можно посмотреть командой sudo fdisk -l ).

Спасибо!) Сделал. Пишет «неизвестный тип файловой системы «crypto Luks»

он у тебя шифрованный что ли?
и покажи вывод
sudo fdisk -l

я правильно тебя понимаю, тебе нужны логи? А как их достать?

Вот пока учился, унал как доставать файлы dmesg.txt и lspci.txt и X.org.0.log
Только прикрепить их сюда не знаю как.

в live cd в консоли вводишь sudo fdisk -l>fdisk.txt и полученный файл показываешь

ты какой раздел подключал sda1 или sda5? как я понимаю нужно подключать первый
sudo mount /dev/sda1 /mnt

Скорее всего никаких проблем с монтированием разделов у Вас нет. Если Вы сами ничего не меняли в файле fstab (он находится по адресу: /etc/fstab), то ещё до загрузки xorg (графической подсистемы) корневой раздел, да и все остальные указанные в этом самом fstab разделы будут проверятся на наличие ошибок. Если у Вас никаких проверок во время загрузки не происходит значит всё в порядке с разделами (при условии, что Вы ничего в fstab не меняли).

Такое поведение как правило означает ошибки при загрузке окружения рабочего стола, причём такие которые приводят к краху и, соответственно, перезапуску x-сервера (xorg). Вот почему Вас постоянно выбрасывает к диалогу входа в систему.

Скажите бывало ли такое ранее и, если не бывало, то что вы делали до последней злополучной перезагрузки?

Вы случайно не пробовали обновлять систему или менять DM (например KDM на LightDM или наоборот LightDM —> KDM)?

а ещё бывает с правами лажа
alt+F1 под рутом
chown -R юзерник:юзерник /home/юзерник

Источник

Таймаут запроса пароля при выполнении sudo

При выполнении команд через sudo при первом запуске запрашивается пароль. Последующие команды выполняются уже без пароля. Через какой-то промежуток времени пароль запрашивается снова. По умолчанию время sudo-сессии 15 минут.

Рассмотрим, как изменить время запроса пароля для sudo, а также, как запрашивать пароль при каждом выполнении sudo.

Изменение времени сессии sudo

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

Откроется текстовый редактор (обычно это nano) с конфигурационным файлом.

Допишите в конце строки через запятую следующую опцию timestamp_timeout=x . Должно получиться:

Здесь 10 — это и есть время в минутах через которое sudo будет запрашивать пароль.

Сохрание изменения и закройте редактор:

• Для этого нажмите сочетание клавиш Ctrl+X .
• Появится сообщение «Сохранить измененный буфер?» (Save modified buffer?), нажмите клавишу Y , чтобы сохранить изменения или N , чтобы отменить изменения.
• Если на предыдущем шаге вы нажали Y , то появится сообщение «Имя фала для записи: /etc/sudoers.tmp» (File Name to Write: /etc/sudoers.tmp) — просто нажмите клавишу Enter .

Запрос пароля при каждом выполнении sudo

Если timestamp_timeout указать равным 0 , то пароль будет запрашиваться при каждом выполнении команды sudo.

Прервать sudo сессию

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

Теперь при следующем выполнении sudo, вновь будет запрошен пароль.

Войти в терминал как root

Предположим, вы открыли окно терминала и вам нужно выполнять какой-то набор команд от имени суперпользователя. Можно перед каждой командой вводить sudo, а можно внутри терминала запустить shell от имени root’а. Для этого используется ключ -s. Выполните команду:

Обратите внимание, что теперь вы работаете от имени пользователя root, поэтому пока вы работаете в данном окне терминала, пароль для sudo вводите не нужно. Чтобы выйти из sudo-сессии (закрыть root-shell) выполните команду exit . sudo -s эквивалентно выполнению команды echo $SHELL .

Видео:

Источник

Для системного администратора

Защита Linux от несанкционированного консольного доступа

Есть две вечные темы, о которых пишет почти каждый автор “блога про linux” — туннели в ssh и сброс пароля root путём загрузки в режиме single user. Как правило, второй рецепт провоцирует обширные обсуждения на тему незащищённости Linux от действий злоумышленников при наличии физического доступа к компьютеру.

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

Итак, как же можно минимально обезопасить свой компьютер?

1. Отключите загрузку с CD-ROM и флэшек и установите пароль на BIOS. Это не позволит злоумышленнику изменить порядок загрузки устройств и загрузиться со своей флэшки или компакт-диска. Однако всегда можно сбросить память BIOS, выковыряв батарейку из материнской платы, поэтому не следует полагаться на пароль BIOS’а в долгосрочной перспективе.
2. Установите пароль на редактирование параметров загрузки grub. Система будет загружаться в обычном порядке, но никто не сможет изменить параметры загрузки, выбрав вариант загрузки и нажав кнопку “e”:
   1. сгенерируйте пароль с помощью утилиты grub-md5-crypt:
   2. Добавьте получившийся пароль в общий раздел /boot/grub/menu.lst в виде строки:
   3. Если у вас есть небезопасные дополнительные режимы загрузки (например, альтернативные операционные системы типа windows, или загрузка с параметром single), можно в описание этих режимов добавить параметр lock, который запретит пользователям выбирать этот вариант загрузки без ввода пароля. Пароль можно задать в этом же разделе, или оставить общий.
   4. Обратите внимание, что если файл menu.lst генерируется программой update-grub, как это сделано в Debian или Ubuntu, то вместо указания директивы lock в каждом варианте загрузки необходимо установить специальные параметры в разделе настройки upgrade-grub: lockalternative, lockold или kopt. Формат этих параметров и механизм работы update-grub подробно описаны в /boot/grub/menu.lst и man update-grub.
3. Если у пользователя root на вашей машине есть пароль, пусть система запрашивает этот пароль при входе в single-user mode. Если в вашем дистрибутиве используется старый стиль инициализации через inittab (к таким системам относится большая часть дистрибутивов, кроме последних версий Ubuntu, Fedora и Debian, перешедших на Upstart), убедитесь, что в /etc/inittab присутствует строчка, подобная следующей:

   Эта инструкция говорит процессу init, что в однопользовательском режиме необходимо запускать программу /sbin/sulogin, которая запрашивает пароль суперпользователя. Но если пароль у root’а отсутствует, как, например, в Ubuntu, то sulogin пропускает в систему без запроса пароля. Поэтому обладателям современных дистрибутивов остаётся утешаться тем, что через пароль grub довольно сложно прорваться.

4. Отключите интерактивную загрузку. В системах, основанных на RedHat (RHEL, Centos, Fedora), пользователь может нажать I перед началом загрузки сервисов и rc.sysinit при старте каждого сервиса будет спрашивать, нужно ли стартовать этот сервис. Эта фича отключается в файле /etc/sysconfig/init исправлением/добавлением параметра PROMPT:
5. Отключите Ctrl+Alt+Del. Любой бездельник может перезагрузить ваш компьютер (и испортить uptime), просто перейдя на виртуальную консоль и нажав три заветные кнопки. Этого риска можно избежать, настроив свой /etc/inittab или, в случае использования upstart, соответствующий файл в /etc/event.d (у меня этот файл так и называется — control-alt-delete). Необходимо просто закомментировать строчку, содержащую описание действия для события ctrlaltdel (или control-alt-delete в Upstart.). Или заменить это действие на команду отправки сообщения в syslog:

   После внесения изменения в /etc/inittab нужно послать процессу init сигнал перечитать этот файл:

   Для Upstart никаких уведомлений об изменении конфигурации не нужно.
   Установите таймаут для логина в консоли. В оболочке bash есть переменная окружения TMOUT, которая устанавливает период неактивности (в секундах) — если от пользователя не поступило никакого ввода в течение указанного времени, процесс bash самоубивается. В /etc/profile.d можно поместить исполняемый файл logintimeout.sh примерно следующего содержания:

   Таким образом, консольные пользователи будут “выкидываться” через 5 минут бездействия. Подобным образом можно установить период неактивности в других шеллах, а также в ssh (параметр ClientInactiveTimeout в sshd_config). Однако мне кажется, что подобные фокусы могут лишь раздражать вас и ваших пользователей, не принося реальной пользы, и стоит ограничиться установкой такого таймаута только для логинов с консоли.

6. Установите vlock и приучите себя и коллег использовать его перед тем, как отлучиться от консоли более чем на 30 секунд. Команда vlock блокирует текущую виртуальную консоль; чтобы разблокировать ее, нужно ввести пароль пользователя или root’а (если он есть, конечно). vlock -a вообще запрещает переключаться на другие консоли (например, с помощью комбинации Alt+F7).
7. Не забывайте о блокировке графического интерфейса.
   1. установите разумный период бездействия (5 — 10 минут), по истечении которого запускается хранитель экрана
   2. установите пароль на хранитель экрана
   3. выведите ярлык блокировки на видное место
   4. назначьте и запомните сочетание клавиш для блокировки экрана (в Gnome это Ctrl+Alt+L)

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

О разном

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

Источник