¿Podemos generar una identificación única para cada PC, algo así como uuuidgen, pero nunca cambiará a menos que haya cambios de hardware? Estaba pensando en fusionar CPUID y MACADDR y hacerlos hash para generar una ID coherente, pero no tengo idea de cómo analizarlos usando el script bash, lo que sé es cómo puedo obtener CPUID de
dmidecode -t 4 | grep ID
y
ifconfig | grep ether
entonces necesito combinar esas cadenas hexadecimales y hacerlas hash usando sha1 o md5 para crear una cadena hexadecimal de longitud fija.
¿Cómo puedo analizar esa salida?
bash
- para generarle un UUID en ningún linux.cat /proc/sys/kernel/random/uuid
.Respuestas:
¿Qué tal estos dos:
Luego puede combinarlos y hacerlos hash con:
Para eliminar el guión final, agregue una tubería más:
Como @mikeserv señala en su respuesta , el nombre de la interfaz puede cambiar entre las botas. Esto significa que lo que es eth0 hoy podría ser eth1 mañana, por lo que si lo
eth0
desea puede obtener una dirección MAC diferente en diferentes botas. Mi sistema no se comporta de esta manera, así que realmente no puedo probar, pero las posibles soluciones son:Busque
HWaddr
en la salida de,ifconfig
pero conserve todos ellos, no solo el correspondiente a una NIC específica. Por ejemplo, en mi sistema tengo:Al tomar ambas direcciones MAC y pasarlas
sha256sum
, debería poder obtener un nombre único y estable, independientemente de qué NIC se llame qué:Tenga en cuenta que el hash es diferente de los anteriores porque estoy pasando ambas direcciones MAC devueltas
ifconfig
asha256sum
.En su lugar, cree un hash basado en los UUID de su (s) disco (s) duro (s):
fuente
En primer lugar, tenga en cuenta que el CPUID definitivamente no es un marcador de identificación único comúnmente accesible para cualquier sistema posterior a un Intel Pentium III. Si bien el hashing con direcciones MAC puede conducir a marcadores únicos, esto se debe solo a las cualidades únicas de los MAC y el CPUID en ese caso no es más que circunstancial. Además, es probable que el hash resultante no sea más exclusivo que el UUID de la placa base, y eso es mucho más fácil de recuperar y el proceso es mucho menos propenso a errar. Desde wikipedia.org/wiki/cpuid :
Puede ver un cpuid analizado usted mismo haciendo
cat /proc/cpuinfo
o incluso simplementelscpu
.Creo que esto le proporciona todas las direcciones MAC para las interfaces de red reconocidas por el kernel de Linux:
Puede ser necesario filtrar esa lista si puede incluir nics virtuales con MAC generados aleatoriamente. Puede hacer esto con banderas en la llamada a
ip
directamente. Consulteip a help
para obtener información sobre cómo hacerlo.También tenga en cuenta que este problema no es exclusivo
ip
y también debe abordarse si lo usaifconfig
, pero que puede manejarse de manera más confiableip
, que es parte deliproute2
conjunto de redes y se mantiene activamente, de lo que puede hacerloifconfig
, que es un miembro delnet-tools
paquete y vimos por última vez un lanzamiento de Linux en 2001 . Debido a las características cambiantes en el núcleo desde su última versión,ifconfig
se sabe que informa erróneamente algunos indicadores de características de red y su uso debe evitarse si es posible.Sin embargo, comprenda que filtrar con nombres de interfaz de kernel como
eth[0-9]
no es un medio confiable para hacerlo, ya que estos pueden cambiar según su orden de detección en paraleloudev
durante el proceso de arranque. Consulte los nombres de red predecibles para obtener más información al respecto.Como
dmidecode
no está instalado en mi sistema, al principio pensé en hacer un hash de una lista de seriales de disco duro generados como:Haga
lsblk --help
algunas pistas para refinar esa lista, por tipo de disco, por ejemplo. También considerelspci
y / olsusb
tal vez.Combinarlos es fácil:
Como me ha informado, está poniendo los recursos del usuario de su lado en sus identificadores únicos, y no se puede confiar en que existan los discos duros, pensé que cambiaría mi táctica.
Dicho esto, busqué nuevamente en el sistema de archivos y encontré la
/sys/class/dmi/id
carpeta. Revisé algunos de los archivos:Sin embargo, este parece ser bastante bueno, pero no publicaré el resultado:
Supongo que de ahí es donde
dmidecode
obtiene gran parte de su información de todos modos y, de hecho, se parece . Segúnman dmidecode
usted, también puede simplificar mucho el uso de esa herramienta especificando el argumento:Sin embargo, aún más simple, solo puede leer el archivo. Tenga en cuenta que este archivo en particular identifica específicamente una placa base. Aquí hay un extracto del parche del kernel de 2007 que implementó originalmente estas exportaciones al
/sysfs
sistema de archivos virtual:Es posible que pueda usar esos datos solo para identificar el sistema, si la placa base es suficiente. Pero puede combinar esta información con los MAC del sistema de la misma manera que demostré que podría hacerlo con los discos duros:
El kernel de Linux también puede generar UUID para usted:
O:
De acuerdo, es generado de forma aleatoria y se tendrá que replantear asignación de ID, pero es casi tan fácil como se pone a conseguir por lo menos. Y debería ser bastante sólido si puedes encontrar un medio para teclearlo.
Por último, en los sistemas UEFI esto es mucho más fácil de hacer, ya que cada variable de entorno de firmware EFI incluye su propio UUID. La variable de entorno
{Platform,}LangCodes-${UUID}
debe estar presente en todos los sistemas UEFI, debe persistir los reinicios e incluso la mayoría de las actualizaciones y modificaciones de firmware, y cualquier sistema Linux con elefivarfs
módulo cargado puede enumerar uno o ambos nombres simplemente como:La forma más antigua,
LangCodes-${UUID}
aparentemente ahora está en desuso , y en los sistemas más nuevos debería estarPlatformLangCodes-${UUID}
, pero, según las especificaciones, uno u otro debería estar presente en cada sistema UEFI. Con poco esfuerzo, puede definir sus propias variables persistentes de reinicio, y tal vez hacer más uso del generador de UUID del núcleo de esa manera. Si está interesado, busque efitools .fuente
ip2
está específicamente diseñado para ser analizado, y puede ser que no lo estoy haciendo lo suficientemente bien; sospecho que se puede hacer lo mismo casi sin élgrep/sed
. Probablemente lo mismo podría hacerse tan fácilmente conudevadm
. Y cada nombre de variable de entorno EFI está diseñado para ser identificado de manera única para exactamente este tipo de situaciones.Muchas distribuciones modernas envían un archivo que
/etc/machine-id
contiene una cadena hexadecimal de 32 caracteres muy probablemente única. Se origina en systemd, donde una página de manual tiene más información , y puede ser apropiada para su propósito.fuente
dbus
específico, creo, y cambia si se borra / reinstala un sistema operativo.En muchas máquinas Linux, el archivo
/var/lib/dbus/machine-id
contiene una identificación única para cada distribución de Linux y se puede acceder mediante una llamada adbus_get_local_machine_id()
. Esto es probablemente lo mismo que lo/etc/machine-id
mencionado anteriormente. Funciona también en instalaciones virtuales de Linux. Lo he comprobado en las distribuciones actuales de Ubuntu, SuSE y CentOS.fuente
/etc/machine-id
.¿Necesita cambiar la ID de la máquina cuando cambia el hardware? ¿Se está utilizando la identificación de la máquina para proteger algo? Creo que la mejor manera de tener una ID de máquina "consistente" es almacenando una cadena aleatoria en algún lugar del sistema y de esa manera si alguno de los cambios de hardware, entonces la ID de la máquina tampoco cambiará. Esto también es bueno para sistemas virtualizados donde el acceso de hardware está restringido y la ID de MAC es 00: 00: 00: 00
Pruebe algo como este script sh para crear y obtener la ID:
fuente
/dev/urandom
indica Linux de todos modos, puede hacer locat /proc/sys/kernel/random/uuid >$FILE
que genera aleatoriamente un UUID formateado correctamente en cada lectura. Aún así, cualquier persistencia implementada en el disco está sujeta a eliminación y, siempre que sea aceptable ydbus
esté instalado, probablemente debería hacer lo que @XZS ha sugerido.Las otras respuestas ofrecen varias formas de extraer identificadores del hardware. Podría decidir usar una pieza de hardware como identificador o muchas. Esto es problemático si necesita intercambiar o reemplazar piezas de hardware arbitrariamente.
En cambio, algunas personas pueden almacenar una identificación generada en su disco duro (o usar el UUID), pero los discos duros pueden ser clonados.
Los módulos TPM y el arranque seguro pueden proporcionar un medio para unir la placa base y otro hardware con una instalación en un disco duro.
Siempre es un poco más fácil en estos casos si proporciona más información sobre lo que desea lograr.
fuente