Можем ли мы сгенерировать уникальный идентификатор для каждого ПК, например, uuuidgen, но он никогда не изменится, если не произойдут аппаратные изменения? Я думал о слиянии CPUID и MACADDR и хешировании их для создания согласованного идентификатора, но я не знаю, как их анализировать с помощью скрипта bash, я знаю, как получить CPUID из
dmidecode -t 4 | grep ID
и
ifconfig | grep ether
затем мне нужно объединить эти шестнадцатеричные строки и хешировать их, используя sha1 или md5, чтобы создать шестнадцатеричную строку фиксированной длины.
Как я могу разобрать этот вывод?
bash
- чтобы генерировать UUID на любом Linux.cat /proc/sys/kernel/random/uuid
,Ответы:
Как насчет этих двух:
Затем вы можете объединить и хешировать их с помощью:
Чтобы удалить концевую черту, добавьте еще одну трубу:
Как отмечает @mikeserv в своем ответе , имя интерфейса может измениться между загрузками. Это означает, что сегодня eth0 может быть eth1 завтра, поэтому, если вы будете использовать grep,
eth0
вы можете получить другой MAC-адрес при разных загрузках. Моя система не работает таким образом, поэтому я не могу на самом деле проверить, но возможные решения:Grep для
HWaddr
на выходеifconfig
но сохраните их все, а не только тот, который соответствует конкретному NIC. Например, в моей системе у меня есть:Захватив оба MAC-адреса и пропустив их через
sha256sum
, вы сможете получить уникальное и стабильное имя, независимо от того, какой сетевой адаптер называется:Обратите внимание, что хеш отличается от приведенных выше, потому что я передаю оба MAC-адреса, возвращенные
ifconfig
вsha256sum
.Вместо этого создайте хэш на основе UUID вашего жесткого диска:
источник
Во-первых, обратите внимание, что CPUID определенно не является общедоступным маркером однозначной идентификации для любой системы, более поздней, чем Intel Pentium III. Хотя хэширование его с MAC-адресами, безусловно, может привести к уникальным маркерам, это связано только с уникальными качествами самих MAC, и CPUID в этом случае является не чем иным, как косвенным. Более того, результирующий хеш, скорее всего, не будет более уникальным, чем UUID материнской платы, и его гораздо проще получить, а процесс менее подвержен ошибкам. Из wikipedia.org/wiki/cpuid :
Вы можете просмотреть разобранный процессор самостоятельно, выполнив
cat /proc/cpuinfo
или даже простоlscpu
.Я думаю, что вы получите все MAC-адреса для сетевых интерфейсов, распознаваемых ядром Linux:
Может возникнуть необходимость отфильтровать этот список, если он может включать виртуальные сети со случайно сгенерированными MAC-адресами. Вы можете сделать это с флагами в вызове
ip
напрямую. Видетьip a help
информацию о том, как это сделать.Также обратите внимание, что эта проблема не является уникальной
ip
и должна также решаться, если вы используетеifconfig
, но она может быть решена более надежноip
- которая является частьюiproute2
сетевого пакета и активно поддерживается - чем она можетifconfig
- которая является членом изnet-tools
пакета и последнего увидела Linux релиза в 2001 году . Из-за изменения функций в ядре с момента его последнего выпускаifconfig
известно, что в них неправильно указаны флаги сетевых функций, и его следует по возможности избегать.Тем не менее, следует понимать, что фильтрация по именам интерфейсов ядра
eth[0-9]
не является надежным средством для этого, поскольку они могут меняться в зависимости от порядка их параллельного обнаруженияudev
во время процесса загрузки. Пожалуйста, смотрите Предсказуемые сетевые имена для более подробной информации.Поскольку
dmidecode
в моей системе не установлено, я сначала подумал о том, чтобы хэшировать список серий жестких дисков, сгенерированных как:Сделайте
lsblk --help
некоторые подсказки по уточнению этого списка - скажем, по типу диска. Также рассмотритеlspci
и / илиlsusb
возможно.Объединить их легко:
Как вы уже сообщали мне, вы настраиваете ресурсы пользователей с их стороны на их уникальные идентификаторы, и на жесткие диски нельзя полагаться, что они существуют, я подумал, чтобы изменить свою тактику.
Учитывая это, я снова заглянул в файловую систему и нашел
/sys/class/dmi/id
папку. Я проверил несколько файлов:Тем не менее, это, кажется, довольно хорошо, но я не буду публиковать вывод:
Я ожидаю, что именно так и
dmidecode
получает большую часть своей информации, и на самом деле это выглядит так . В соответствии с этимman dmidecode
вы также можете значительно упростить использование этого инструмента, указав аргумент:Более простой, тем не менее, вы можете просто прочитать файл. Обратите внимание, что этот конкретный файл специально определяет материнскую плату. Вот отрывок из исправления ядра 2007 года, в котором изначально был реализован этот экспорт в
/sysfs
виртуальную файловую систему:Вы можете использовать эти данные в одиночку для идентификации системы - если материнской платы достаточно. Но вы можете объединить эту информацию с MAC-адресами системы так же, как я продемонстрировал, что вы могли бы сделать с жесткими дисками:
Ядро Linux также может генерировать UUID для вас:
Или:
Конечно, он генерируется случайным образом, и вам придется переосмыслить присвоение идентификатора, но это так же просто, как и получить, по крайней мере. И это должно быть довольно солидно, если вы можете найти средство для его ввода.
Наконец, в системах UEFI это становится гораздо проще сделать, поскольку каждая переменная среды встроенного ПО EFI включает в себя собственный UUID. Переменная окружения
{Platform,}LangCodes-${UUID}
должна присутствовать в каждой системе UEFI, должна сохраняться перезагрузка и даже большинство обновлений и модификаций прошивки, и любая система Linux сefivarfs
загруженным модулем может перечислять одно или оба имени так же просто, как:Старая форма -
LangCodes-${UUID}
по-видимому, сейчас устарела , и на более новых системах должна быть,PlatformLangCodes-${UUID}
но, согласно спецификации, одна или другая должна присутствовать в каждой системе UEFI. Без особых усилий вы можете определить свои собственные постоянные переменные перезагрузки и, возможно, более активно использовать генератор UUID ядра таким образом. Если интересно, загляните в efitools .источник
ip2
специально разработан для анализа, и, возможно, я недостаточно хорошо это делаю - подозреваю, что то же самое можно сделать почти без негоgrep/sed
. Вероятно, то же самое можно сделать так же легко сudevadm
. И каждое имя переменной среды EFI предназначено для уникальной идентификации именно для таких ситуаций.Многие современные дистрибутивы поставляют файл,
/etc/machine-id
содержащий наиболее вероятно уникальную шестнадцатеричную 32-символьную строку. Он происходит из systemd, где на man-странице есть больше информации , и может подходить для ваших целей.источник
dbus
специфично, я думаю, и меняется, если операционная система стерта / переустановлена.На многих машинах Linux файл
/var/lib/dbus/machine-id
содержит уникальный идентификатор для каждого дистрибутива Linux и может быть доступен с помощью вызоваdbus_get_local_machine_id()
. Это, вероятно, то же самое, что/etc/machine-id
упомянуто выше. Это работает и на виртуальных установках Linux. Я проверил это на текущих дистрибутивах Ubuntu, SuSE и CentOS.источник
/etc/machine-id
.Вам нужен идентификатор машины, чтобы измениться, когда меняется оборудование? Используется ли идентификатор машины для защиты чего-либо? Я считаю, что лучший способ иметь «согласованный» идентификатор машины - это хранить случайную строку где-то в системе, и таким образом, если любое из аппаратных средств изменится, идентификатор машины также не изменится. Это также хорошо для виртуализированных систем, где доступ к оборудованию ограничен, а MAC-адрес - 00: 00: 00: 00.
Попробуйте что-то вроде этого скрипта sh, чтобы создать и получить ID:
источник
/dev/urandom
любом случае указываете на Linux, вы можете просто сделать,cat /proc/sys/kernel/random/uuid >$FILE
что случайным образом генерирует правильно отформатированный UUID при каждом чтении. Тем не менее, любое сохраняемое на диске постоянство подлежит удалению, и, при условии, что это приемлемо и при условииdbus
установлено, вам, вероятно, следует поступить так, как предложил @XZS.Другие ответы дают несколько способов извлечь идентификаторы из аппаратного обеспечения. Вы можете решить использовать одну часть оборудования в качестве идентификатора или несколько. Это проблематично, если вам нужно произвольно поменять или заменить части оборудования.
Некоторые люди могут вместо этого сохранить идентификатор сгенерированного идентификатора на своем жестком диске (или использовать UUID), но жесткие диски могут быть клонированы.
Модули TPM и безопасная загрузка могут обеспечить средства привязки материнской платы и другого оборудования к установке на жесткий диск.
В таких случаях всегда немного легче, если вы дадите больше информации о том, чего хотите достичь.
источник