Требуется аутентификация при помощи при запуске ОС [закрыто]

Это зависит от того, что Вы подразумеваете под начальной загрузкой, но скорее всего то, что Вы хотите, может быть сделано путем добавления пользовательской записи в systemd.
https://www.freedesktop.org/wiki/Software/systemd/-systemd Wiki.
https://wiki.archlinux.org/index.php/systemd#Writing_unit_files - дуга запись Wiki на systemd.

---

Управляемый для создания сервиса, который делает что-то близко к тому, что Вы спросили, добавив решение.

Disclamer: я реализовал и протестировал этот процесс в ПОМОЩНИКЕ Ubuntu 17.04. Это должно работать в 16,04 или выше, но в более старых версиях могут быть проблемы. Также стоящий замечания, что systemd не использовался в версиях значительно старше Ubuntu также.

Создание сценария удара, который выполнит нашу подлинную проверку путем проверки, подключено ли определенное USB-устройство.

В первую очередь, мы должны создать сценарий удара для выполнения нашей "подлинной" проверки. Вот пример сценария для выполнения проверки на основе связанного идентификатора USB-устройства:

#!/bin/bash
# test usb auth script
CHECKID="0461:4de3"
READID=$( lsusb -d "$CHECKID" | awk '{print $6}' )
wait
printf "Required: ${CHECKID} \nObtained: ${READID}\n"
if [ "$CHECKID" == "$READID" ]
then
    echo "Usb-auth check passed!"
else
    echo "Usb-auth check failed!"
    echo 'Calling for shutdown...'
    shutdown 0
fi

CHECKID содержит предопределенный идентификатор производителя устройств и самого устройства.
READID переменная получит результат работающей команды, содержавшей внутри $( ), в этом случае это будет lsusb -d "$CHECKID" | awk '{print $6}'.
lsusb -d "$CHECKID" попытается найти устройство с идентификатором сохраненным в переменной $CHECKID, в то время как awk '{print $6}' проанализирует результат для сохранения только Word номер 6 в законченной строке. Например, lsusb -d "0461:4de3" в моей системе возвращает это:
Bus 002 Device 003: ID 0461:4de3 Primax Electronics, Ltd
и 6-е слово в этом выводе является точно идентификатором устройства.
wait вызов скажет сценарию ожидать, пока любая из наших предыдущих дочерних команд не будет сделана перед хождением дальше к сравнению.
printf включен только в logging\debugging целях.
if [ "$CHECKID" == "$READID" ] то, где фактическая проверка осуществляется. В выдерживает сравнение CHECKID с READID, и если они равны, мы прошли проверку, иначе мы не сделали и завершение работы будет выполняться.

Пошаговый процесс:

1. Создайте файл сценария удара.
Перейдите к /usr/local/bin при наличии полномочий пользователя root (при использовании nautilus\caja можно открыться /usr/local, щелкните правой кнопкой по папке "мусорного ведра" и использованию, "открытому как администратор" опция). Эта папка используется для определения местоположения пользовательских сценариев в масштабе всей системы. Сценарии локального пользователя могут быть созданы в /home/[user]/bin вместо этого. Создайте пустой файл и откройте его со своим предпочтительным текстовым редактором. Заполните его своим сценарием проверки как пример, я буду использовать проверку USB-устройства сверху:

#!/bin/bash
# test usb auth script
CHECKID="0461:4de3"
READID=$( lsusb -d "$CHECKID" | awk '{print $6}' )
wait
printf "Required: ${CHECKID} \nObtained: ${READID}\n"
if [ "$CHECKID" == "$READID" ]
then
    echo "Usb-auth check passed!"
else
    echo "Usb-auth check failed!"
    echo 'Calling for shutdown...'
    #shutdown 0
fi  

Я использовал "#", чтобы прокомментировать фактический вызов завершения работы, предотвратить завершение работы во время установки и тестов. Ради простоты примера мы предположим, что сценарий называют usb-auth и полный путь /usr/local/bin/usb-auth. Я буду использовать его на будущих шагах, поэтому удостоверьтесь, что изменили их при использовании другого имени файла или пути.

2. Дайте свои полномочия руководителя сценария. Можно сделать это путем выполнения команды sudo chmod +x [file], в моем случае это будет:
sudo chmod +x /usr/local/bin/usb-auth

3. Узнайте идентификатор устройства, которое Вы хотите использовать.

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

lsusb
Bus 002 Device 006: ID 0480:b206 Toshiba America Inc 
Bus 002 Device 005: ID 8086:0189 Intel Corp. 
Bus 002 Device 004: ID 0b38:0010 Gear Head 107-Key Keyboard
Bus 002 Device 003: ID 0461:4de3 Primax Electronics, Ltd 

Устройство 003 в этом случае является моей мышью, и это будет использоваться в нашей проверке, таким образом, нам будет нужен идентификатор "0461:4de3". После того, как мы получили его, мы можем сохранить его в нашем сценарии как основа для проверки в этой строке:
CHECKID = "0461:4de3"

4. Проверьте свой сценарий в терминал, чтобы удостовериться, что он работает, как предназначено.
Удостоверьтесь, что вызов завершения работы комментируется во время тестов. Просто имя типа Вашего сценария в терминале и это должно автоматически взять его, потому что мы определили местоположение его в ''/usr/local/bin /'.
Сверение с подключенным устройством:

ethuil~$ usb-auth 
Required: 0461:4de3 
Obtained: 0461:4de3
Check passed!

Отключите устройство, проверьте снова:

ethuil~$ usb-auth 
Required: 0461:4de3 
Obtained: 
Check failed!
Executing shutdown...

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

Создание systemd сервис для вызова сценария удара

5. Создайте сервисный файл и найдите его в/etc/systemd/system/.
Вам будут нужны полномочия пользователя root снова для этого. Создайте пустой файл с расширением .service, Я назову мой auth-usb.service.
Откройте его со своим текстовым редактором и заполните его содержанием как это:

[Unit]
Description=usb-auth bash script
After=network-online.target

[Install]
WantedBy=sysinit.target

[Service]
ExecStart=/bin/bash /usr/local/bin/usb-auth
Type=oneshot
RemainAfterExit=yes  

Разрушение этой части:

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

After - это свойство указывает, после которого сервиса мы должны запустить наш сценарий. В этом примере у нас есть "сеть-online.target", что означает, что наш сценарий будет запущен только после того, как сеть будет онлайн. Эта часть может быть важной, если Ваш сценарий использует части системы, затронутой другими услугами, например, сетевым соединением в этом примере. Можно перечислить всю основную целевую сервисную команду использования:
systemctl list-units --type=target
При поиске определенного сервиса, чтобы произойти, когда Вы запускаете свой скрипт, можно перечислить всю сервисную команду использования:
systemctl list-unit-files

WantedBy - это - важная часть, которая определит, в какой точке назовут наш сервис. Обычно пользовательские сценарии будут использовать "WantedBy=multi-user.target" и бежать за системой, запускается и полностью рабочий. В нашем случае мы будем использовать "sysinit.target", чтобы заставить его работать во время системной инициализации. Если Вы хотите запустить скрипт в другое время, можно использовать то же systemctl list-units --type=target как прежде для списка возможных значений. В моем примере я буду придерживаться "sysinit.target".

Больше о [Единице] и [Установке] части:
https://www.freedesktop.org/software/systemd/man/systemd.unit.html# % 5BUnit%5D%20Section%20Options

ExecStart - это - то, где мы говорим то, что точно мы хотим, чтобы наш сервис выполнил. "/bin/bash" выполнит интерпретатор удара и "/usr/local/bin/usb-auth" передается как параметр, чтобы сказать ему местоположение сценария для выполнения. Если Вы планируете использовать не, колотят сценарий, но фактическую самодельную программу, можно указать путь к программе вместо "/bin/bash *".
Type=oneshot - это - тип нашего сервиса. RemainAfterExit=yes - эта часть говорит, что система рассмотрит наш сервис как активный даже после того, как все его названные процессы выйдут.

Больше о различных типах и [Сервисе] часть:
https://www.freedesktop.org/software/systemd/man/systemd.service.html#Type =

6. Включите наш недавно созданный сервис.
Теперь, когда мы создали наш /etc/systemd/system/auth-usb.service и /usr/local/bin/usb-auth файлы, мы можем включить наш сервис путем выполнения команды systemctl enable [service filename]:

ethuil~$ systemctl enable auth-usb.service
Created symlink /etc/systemd/system/sysinit.target.wants/auth-usb.service → /etc/systemd/system/auth-usb.service.

Больше о systemctl команда:
https://www.freedesktop.org/software/systemd/man/systemctl.html#start%20PATTERN%E2%80%A6
7. Проверьте, работает ли наш сервис.
Команда выполнения systemctl restart auth-usb.service выполнять наш сервис проверки.
После того, как Вы сделали это, проверьте журналы, чтобы видеть, работает ли это, как предназначено использующий команду journalctl -u auth-usb.
В моем случае:

ethuil~$ systemctl restart auth-usb.service
ethuil~$ journalctl -u auth-usb
-- Logs begin at Tue 2017-07-25 19:15:23 EEST, end at Tue 2017-07-25 19:15:52 EEST. --
Jul 25 19:15:49 ethuil-300E5Z systemd[1]: Starting usb-auth bash script...
Jul 25 19:15:49 ethuil-300E5Z bash[1262]: Required: 0461:4de3
Jul 25 19:15:49 ethuil-300E5Z bash[1262]: Obtained: 0461:4de3
Jul 25 19:15:49 ethuil-300E5Z bash[1262]: Check passed!
Jul 25 19:15:52 ethuil-300E5Z systemd[1]: Started usb-auth bash script.

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

8. Система перезапуска и видит, была ли она запущена во время системного запуска, как предназначено. Сам объяснительный. Просто перезапустите ПК и работайте journalctl -u auth-usb видеть если сервис, выполненный, как это должно. Если что-то не работает то же во время запуска как во время полностью рабочей системы, это - способ, которым можно проверить его путем перезапуска и проверки журнала. Можно также работать journalctl -t systemd видеть, в которой точке системы запускают Ваш сервис, начинает, и посмотрите, необходимо ли изменить это.

9. Команда "завершения работы" некомментария в Вашем сценарии.
Часть некомментария Вашего скрипта, который должен быть запущен, если бы проверка перестала работать и система перезапуска, чтобы видеть, работает ли Ваш сценарий проверки. Это - последняя проверка, попробуйте рабочий ПК своим подключенным устройством и без, чтобы видеть, хорошо работает ли это. Удостоверьтесь, что у Вас есть способы получить доступ к сценарию, если Вы привычка смочь пройти проверку сами, например, при наличии внешней карты с интерфейсом USB с системой, от которой можно загрузить и изменить сценарий.

10. Это - это, мы сделаны. Теперь можно улучшить процесс для установки личной нужде.
В этой точке можно просто изменить целый процесс для установки потребностям. Сделайте более сложный сценарий удара или создайте полностью функциональную программу вместо этого, доберитесь до проверки который USB-порт Вы соединительное устройство к, делая что-то еще вместо завершения работы (например, тихое журналирование несанкционированного действия вместо того, чтобы просто закрыться) и т.д. Всегда, это было бы за пределами объема этого ответа. Я действительно пытался заставить его работать с MAC-адресом, и возможно сделать, но моя текущая установка не имеет надлежащего и надежного способа протестировать его правильно и стабильный, таким образом, я не включал тот пример.