一貫したマシン固有IDを生成する

uuuidgenなど、PCごとに一意のIDを生成できますが、ハードウェアの変更がない限り変更されませんか？CPUIDとMACADDRをマージしてハッシュして一貫したIDを生成することを考えていましたが、bashスクリプトを使用してそれらを解析する方法がわかりません。

dmidecode -t 4 | grep ID

そして

ifconfig | grep ether

次に、これらの16進文字列を結合し、sha1またはmd5を使用してハッシュして、固定長の16進文字列を作成する必要があります。
その出力をどのように解析できますか？

これら2つはどうですか：

$ sudo dmidecode -t 4 | grep ID | sed 's/.*ID://;s/ //g'
52060201FBFBEBBF
$ ifconfig | grep eth1 | awk '{print $NF}' | sed 's/://g'
0126c9da2c38

次に、これらを組み合わせてハッシュ化できます。

$ echo $(sudo dmidecode -t 4 | grep ID | sed 's/.*ID://;s/ //g') \
       $(ifconfig | grep eth1 | awk '{print $NF}' | sed 's/://g') | sha256sum 
59603d5e9957c23e7099c80bf137db19144cbb24efeeadfbd090f89a5f64041f  -

末尾のダッシュを削除するには、もう1つのパイプを追加します。

$ echo $(sudo dmidecode -t 4 | grep ID | sed 's/.*ID://;s/ //g') \
       $(ifconfig | grep eth1 | awk '{print $NF}' | sed 's/://g') | sha256sum |
  awk '{print $1}'
59603d5e9957c23e7099c80bf137db19144cbb24efeeadfbd090f89a5f64041f

@mikeserv が彼の答えで指摘しているように、インターフェイス名はブートごとに変わる可能性があります。これは、今日のeth0が明日eth1になる可能性があることを意味しeth0ます。私のシステムはこのように動作しないため、実際にテストすることはできませんが、考えられる解決策は次のとおりです。

1. 特定のNICに対応するものだけでなく、すべてのHWaddr出力でGrepを使用しifconfigます。たとえば、私のシステムには次のものがあります。

   $ ifconfig | grep HWaddr
   eth1      Link encap:Ethernet  HWaddr 00:24:a9:bd:2c:28  
   wlan0     Link encap:Ethernet  HWaddr c4:16:19:4f:ac:g5  

   両方のMACアドレスsha256sumを取得して通過させることにより、どのNICが何と呼ばれているかに関係なく、一意で安定した名前を取得できるはずです。

   $ echo $(sudo dmidecode -t 4 | grep ID | sed 's/.*ID://;s/ //g') \
        $(ifconfig | grep -oP 'HWaddr \K.*' | sed 's/://g') | sha256sum |
         awk '{print $1}'
   662f0036cba13c2ddcf11acebf087ebe1b5e4044603d534dab60d32813adc1a5    

   ifconfigtoが返すMACアドレスの両方を渡すため、ハッシュは上記のものとは異なることに注意してくださいsha256sum。

2. 代わりに、ハードドライブのUUIDに基づいてハッシュを作成します。

   $ blkid | grep -oP 'UUID="\K[^"]+' | sha256sum | awk '{print $1}'
   162296a587c45fbf807bb7e43bda08f84c56651737243eb4a1a32ae974d6d7f4

まず、CPUIDは間違いであることに注意を喜ばない、後のIntel Pentium III以上の任意のシステムのために一般的にアクセス可能一意に識別マーカー。MACアドレスでハッシュすることで確実に一意のマーカーが得られる可能性がありますが、これはMAC自体の一意の品質のみによるものであり、その場合のCPUIDは状況にすぎません。さらに、結果のハッシュはマザーボードのUUIDよりも一意である可能性は低く、それを取得する方がはるかに簡単であり、プロセスのエラーがはるかに少なくなります。wikipedia.org/wiki/cpuidから：

EAX = 3：プロセッサーのシリアル番号

参照：Pentium III§プライバシーの問題に関する論争

これは、プロセッサのシリアル番号を返します。プロセッサのシリアル番号はIntel Pentium IIIで導入されましたが、プライバシーの問題により、この機能は後のモデルでは実装されなくなりました（PSN機能ビットは常にクリアされます）。TransmetaのEfficeonおよびCrusoeプロセッサもこの機能を提供します。ただし、AMD CPUは、どのCPUモデルにもこの機能を実装していません。

解析したcpuidを自分で表示することcat /proc/cpuinfoも、単に実行することもできますlscpu。

これにより、Linuxカーネルによって認識されるネットワークインターフェイスのすべてのMACアドレスが取得されます。

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

ランダムに生成されたMACを持つ仮想NICが含まれている可能性がある場合、そのリストをフィルタリングする必要があります。これを行うには、ip直接呼び出しのフラグを使用します。ip a helpその方法については、を参照してください。

また、この問題は固有のものではなく、ip使用する場合にも対処する必要がありますが、ネットワークスイートの一部であり、アクティブに維持される- メンバーifconfigよりも確実に処理できることに注意してくださいパッケージと最後ののこぎり、Linuxの2001年にリリース。前回のリリース以降にカーネルの機能が変更されたため、一部のネットワーク機能フラグを誤って報告することが知られており、可能な限りその使用を避ける必要があります。ipiproute2ifconfignet-toolsifconfig

ただし、カーネルインターフェイス名のようなフィルタリングeth[0-9]はそうするための信頼できる手段ではないことを理解してください。これらudevはブートプロセス中の並列検出の順序に基づいて変化する可能性があるためです。詳細については、予測可能なネットワーク名を参照してください。

dmidecodeシステムにインストールされていないため、最初に次のように生成されたハードディスクシリアルのリストをハッシュ化することを考えました。

lsblk -nro SERIAL

ください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

通知されたように、ユーザーのリソースを一意のIDにキー入力しているため、ハードディスクが存在することに依存できないため、タックを変更することを考えました。

それを考慮して、私はファイルシステムをもう一度調べて、/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

確かに、それはランダムに生成され、IDの割り当てを再考する必要がありますが、少なくとも簡単に取得できます。そして、それをキーイングする手段を見つけることができれば、それはかなりしっかりしているはずです。

最後に、UEFIシステムでは、これがはるかに簡単になります-すべてのEFIファームウェア環境変数には独自のUUIDが含まれているためです。環境変数{Platform,}LangCodes-${UUID}はすべてのUEFIシステムに存在する必要があり、再起動およびほとんどのファームウェアのアップグレードと変更を維持する必要があり、efivarfsモジュールがロードされたLinuxシステムはいずれかまたは両方の名前を単純に次のようにリストできます。

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

古い形式- LangCodes-${UUID}明らかに非推奨になり、新しいシステムでは廃止されるはずですPlatformLangCodes-${UUID}が、仕様によれば、いずれかのUEFIシステムにいずれかが存在する必要があります。わずかな労力で、独自の再起動永続変数を定義でき、その方法でカーネルのUUIDジェネレーターをさらに活用できます。興味があれば、efitoolsを調べてください。

最新のディストリビューションの多くは/etc/machine-id、おそらく一意の16進数の32文字の文字列を含むファイルを出荷しています。これは、マンページに詳細な情報がある systemdに由来し、目的に適している場合があります。

多くのLinuxマシンでは、ファイルに/var/lib/dbus/machine-idは各Linuxディストリビューションの一意のIDが含まれており、への呼び出しによってアクセスできますdbus_get_local_machine_id()。これはおそらく上記と同じ/etc/machine-idです。仮想Linuxインストールでも機能します。現在のUbuntu、SuSE、CentOSディストリビューションで確認しました。

ハードウェアの変更時にマシンIDを変更する必要がありますか？マシンIDは何かを保護するために使用されていますか？「一貫性のある」マシンIDを持っていると私が信じる最良の方法は、システムのどこかにランダムな文字列を保存することです。これは、ハードウェアアクセスが制限され、MAC IDが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;

他の答えは、ハードウェアからIDを抽出するいくつかの方法を提供します。1つまたは複数のハードウェアを識別子として使用することもできます。これは、ハードウェアを任意に交換または交換する必要がある場合に問題になります。

代わりに、生成されたIDをハードドライブに保存する（またはUUIDを使用する）場合もありますが、ハードドライブは複製できます。

TPMモジュールとセキュアブートは、マザーボードやその他のハードウェアをハードドライブにインストールするための手段を提供します。

達成したいことについてもっと情報を提供すれば、これらのケースでは常に少し簡単になります。