генерируйте последовательный уникальный идентификатор машины

] Многие современные дистрибутивы поставляют файл []/etc/machine-id[], содержащий, скорее всего, уникальную шестнадцатеричную 32-символьную строку. Он берется из systemd, где []manpage имеет больше информации [], и может быть подходящим для ваших целей.[

] Нужно ли менять идентификатор машины при смене аппаратного обеспечения? Используется ли идентификатор машины для защиты? Лучший способ, на мой взгляд, иметь "последовательный" ID машины - это хранить где-нибудь в системе случайную строку, и таким образом, если что-то изменится в аппаратном обеспечении, ID машины тоже не изменится. Это также хорошо для виртуализированных систем, где аппаратный доступ ограничен, а идентификатор MAC - 00:00:00:00[

]Попробуйте что-нибудь вроде этого скрипта sh, чтобы создать и получить ID:[

#!/bin/sh
FILE="/etc/machine-id"

if [ ! -f $FILE ]; then
    cat /dev/urandom|tr -dc A-Z0-9|head -c32 > $FILE;
fi

cat $FILE;

Во-первых, обратите внимание, что CPUID определенно не общедоступный однозначно идентифицирующий маркер для любой системы, более поздней, чем Intel Pentium III. Хотя хеширование с помощью MAC-адресов, безусловно, может привести к появлению уникальных маркеров, это связано только с уникальными качествами самих MAC-адресов, и CPUID в этом случае не более чем косвенный. Более того, полученный хэш вряд ли будет более уникальным, чем UUID материнской платы, и его гораздо легче получить, а процесс гораздо менее подвержен ошибкам. Из wikipedia.org/wiki/cpuid :

EAX = 3 : Серийный номер процессора

См. Также: Pentium III § Споры по вопросам конфиденциальности

Это возвращает серийный номер процессора. Серийный номер процессора был введен в Intel Pentium III, но из соображений конфиденциальности эта функция больше не реализована в более поздних моделях (бит функции PSN всегда сброшен). Процессоры Transmeta Efficeon и Crusoe также предоставляют эту функцию. Однако процессоры AMD не поддерживают эту функцию ни в каких моделях процессоров.

Вы можете просмотреть проанализированный процессор самостоятельно, выполнив cat / proc / cpuinfo или даже просто lscpu .

Это дает вам все MAC-адреса для сетевых интерфейсов, распознаваемых ядром Linux, я думаю:

ip a | sed '\|^ *link[^ ]* |!d;s|||;s| .*||'

Возможно, потребуется отфильтровать этот список, если он может включать виртуальные сетевые устройства со случайно сгенерированными MAC-адресами. Вы можете сделать это с помощью флагов в вызове ip напрямую. См. ip a help для получения информации о том, как это сделать.

Также обратите внимание, что эта проблема не уникальна для ip и ее также необходимо решать, если вы используете ifconfig , но что ее можно более надежно решить с помощью ip , который является частью сетевого пакета iproute2 и активно поддерживается - чем с помощью ifconfig , который является членом net-tools пакет и последний раз выпуск Linux был в 2001 году . Из-за изменения функций в ядре с момента его последнего выпуска ifconfig , как известно, неверно сообщает о некоторых флагах сетевых функций , и его использования следует избегать, если это вообще возможно.

Однако следует понимать, что фильтрация с использованием имен интерфейсов ядра, таких как eth [0-9] , не является надежным средством для этого, поскольку они могут меняться в зависимости от порядка параллельного обнаружения с помощью udev во время загрузки. См. Предсказуемые сетевые имена для получения дополнительной информации.

Поскольку dmidecode не установлен в моей системе, я сначала подумал хэшировать список серийных номеров жесткого диска, сгенерированный наподобие:

lsblk -nro SERIAL

Do lsblk --help для некоторых подсказок по уточнение этого списка - скажем, по типу диска. Также рассмотрите возможность lspci и / или lsusb .

Комбинировать их легко:

{ ip a | sed ... ; lsblk ... ; } | #abbreviated... for brevity...
    tr -dc '[:alnum:]' | #deletes all chars not alphanumeric - including newlines
    sha256sum #gets your hash

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

Учитывая это, я снова заглянул в файловую систему и нашел папку / sys / class / dmi / id . Я проверил несколько файлов:

cat ./board_serial ./product_serial

###OUTPUT###
To be filled by O.E.M.
To be filled by O.E.M.

Тем не менее, этот выглядит довольно неплохо, но я не буду публиковать вывод:

sudo cat /sys/class/dmi/id/product_uuid

Я думаю, что dmidecode все равно получает большую часть информации именно здесь. и на самом деле он действительно выглядит так . Согласно man dmidecode вы также можете значительно упростить использование этого инструмента, указав аргумент:

dmidecode -s system-uuid

Еще проще, но вы можете просто прочитать файл. Обратите внимание, что этот конкретный файл определяет материнскую плату. Вот отрывок из патча ядра 2007 , который изначально реализовывал этот экспорт в виртуальную файловую систему / sysfs :

+DEFINE_DMI_ATTR_WITH_SHOW(bios_vendor,      0444, DMI_BIOS_VENDOR);
+DEFINE_DMI_ATTR_WITH_SHOW(bios_version,         0444, DMI_BIOS_VERSION);
+DEFINE_DMI_ATTR_WITH_SHOW(bios_date,        0444, DMI_BIOS_DATE);
+DEFINE_DMI_ATTR_WITH_SHOW(sys_vendor,       0444, DMI_SYS_VENDOR);
+DEFINE_DMI_ATTR_WITH_SHOW(product_name,         0444, DMI_PRODUCT_NAME);
+DEFINE_DMI_ATTR_WITH_SHOW(product_version,   0444, DMI_PRODUCT_VERSION);
+DEFINE_DMI_ATTR_WITH_SHOW(product_serial,    0400, DMI_PRODUCT_SERIAL);
+DEFINE_DMI_ATTR_WITH_SHOW(product_uuid,         0400, DMI_PRODUCT_UUID);
+DEFINE_DMI_ATTR_WITH_SHOW(board_vendor,         0444, DMI_BOARD_VENDOR);
+DEFINE_DMI_ATTR_WITH_SHOW(board_name,       0444, DMI_BOARD_NAME);
+DEFINE_DMI_ATTR_WITH_SHOW(board_version,     0444, DMI_BOARD_VERSION);
+DEFINE_DMI_ATTR_WITH_SHOW(board_serial,         0400, DMI_BOARD_SERIAL);
+DEFINE_DMI_ATTR_WITH_SHOW(board_asset_tag,   0444, DMI_BOARD_ASSET_TAG);
+DEFINE_DMI_ATTR_WITH_SHOW(chassis_vendor,    0444, DMI_CHASSIS_VENDOR);
+DEFINE_DMI_ATTR_WITH_SHOW(chassis_type,         0444, DMI_CHASSIS_TYPE);
+DEFINE_DMI_ATTR_WITH_SHOW(chassis_version,   0444, DMI_CHASSIS_VERSION);
+DEFINE_DMI_ATTR_WITH_SHOW(chassis_serial,    0400, DMI_CHASSIS_SERIAL);
+DEFINE_DMI_ATTR_WITH_SHOW(chassis_asset_tag, 0444, DMI_CHASSIS_ASSET_TAG);

Вы можете использовать только эти данные для идентификации системы - если материнской платы достаточно. Но вы можете объединить эту информацию с MAC-адресами системы так же, как я продемонстрировал, что вы можете сделать это с жесткими дисками:

sudo sh <<\CMD | tr -dc '[:alnum:]' | sha256sum
        ip a | sed '\|^ *link[^ ]* |!d;s|||;s| .*||'
        cat /sys/class/dmi/id/product_uuid 
CMD

Ядро Linux также может генерировать для вас UUID:

cat /proc/sys/kernel/random/uuid #new random uuid each time file is read

Или:

cat /proc/sys/kernel/random/boot_id #randomly generated per boot

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

Наконец, в системах UEFI это становится намного проще сделать, поскольку каждая переменная среды встроенного ПО EFI включает свой собственный UUID. Переменная среды {Platform,} LangCodes - $ {UUID} должна присутствовать в каждой системе UEFI, должна сохраняться при перезагрузках и даже большинстве обновлений и модификаций прошивки, а также в любой системе Linux с Загруженный модуль efivarfs может перечислять одно или оба имени так же просто, как:

printf '%s\n' /sys/firmware/efi/efivars/*LangCodes-*

Старая форма - LangCodes - $ {UUID} , по-видимому, теперь устарела , и в новых системах должно быть PlatformLangCodes - $ {UUID} , но, согласно спецификации, тот или иной должен присутствовать в каждой системе UEFI. С небольшими усилиями вы можете определить свои собственные постоянные переменные перезагрузки и, возможно, таким образом больше использовать генератор UUID ядра. Если интересно, загляните в efitools .

На многих машинах Linux файл / var / lib / dbus / machine-id содержит уникальный идентификатор для каждого распределения Linux и может получить доступ к вызову к DBUS_GET_LOCAL_MACHINE_ID () . Это, вероятно, так же, как / etc / machine-id , упомянутый выше. Он работает на виртуальных установках Linux. Я проверил его на текущих распределениях Ubuntu, Suse и Centos.

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

Некоторые люди могут вместо этого хранить id сгенерированный идентификатор на своем жестком диске (или использовать UUID), но жесткие диски можно клонировать.

Модули TPM и безопасная загрузка могут предоставить средства привязки материнской платы и другого оборудования к установке на жесткий диск.

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