Linux Discoveryの失敗は、まず「どこまで成功したか」を記録すると調べやすくなります。通信、SSH認証、Linuxの権限、情報収集、CMDBへの反映を一つずつ分け、最後に成功した段階の次を確認します。
この記事は、すでにあるDiscovery実行結果から調査を始めるための手順です。仕組みの説明は導入編「ServiceNow MID ServerからLinuxをDiscoveryする仕組みを初心者向けに整理」に譲り、ここでは確認場所、コマンドの意味、結果の限界を扱います。
資料確認日：2026-10-07。 ServiceNowはAustralia版資料を参照しています。対象OS・製品リリース・Patternの版が異なる場合は、対応資料と実装を確認してください。
コード検証の範囲： 2026-10-08の検証記録では、隔離したDebian 13環境でgetent、id／groups、およびlocalhostのOpenSSH接続を確認しています。SSHは正常接続に加え、未登録・不一致のホスト鍵、認証鍵の不一致、接続拒否を確認しています。接続先・アカウント・ポート・鍵は検証用に置き換えており、実MID Serverの接続条件ではありません。sudo、Windows PowerShell、systemdホスト上のサービス状態、実journalの抽出、およびServiceNow／MID Server／Discovery／CMDBの実動作は未検証です。以下のコマンドは、管理者が許可した検証環境で利用を検討するための例です。
本文では、SSH（Secure Shell、暗号化されたリモート接続）、DNS（Domain Name System、名前とアドレスなどの対応付け）、TCP（Transmission Control Protocol、SSH等が使う通信方式）、CMDB（構成管理データベース）、CI（構成アイテム）という用語を使います。MID ServerはServiceNowの指示を受けて対象へアクセスする実行役です。OSはOperating Systemの略です。
0. 再実行する前に調査条件をそろえる
最初に、既存のDiscovery実行結果から対象、実行時刻とタイムゾーン、選択されたMID Server、失敗した処理、表示されたメッセージを記録します。「どのMID Serverが、いつ、どの対象で失敗したか」が分からないと、別の通信やログを比較してしまいます。
調査メモは組織内の許可された場所に保存し、実際のホスト名・IPアドレス・資格情報・ログを公開記事へ転記しません。本文の linux01.example.com、192.0.2.10、discovery_user は説明用の架空値です。実際の接続先として実行しないでください。
図3 MIDの利用可否、対象への通信、SSH認証、情報取得、CI反映の順で、未確認または失敗した段階の確認先を選ぶ
図3は独自の調査順序であり、ServiceNowの正式なDiscoveryフェーズ図ではありません。過去の証拠で確認できた段階は読み飛ばし、必要な箇所へ進みます。
1. MID Serverの状態と対象への到達性を分ける
ServiceNow側で、選択されたMID Serverの状態と、該当実行の結果を確認します。MID Serverのheartbeatは、インスタンスとの通信・稼働状態を把握する材料です。対象LinuxのSSH認証や情報収集まで保証するものではありません。T11
ここでインスタンスとMID Serverの通信に問題があれば、対象Linuxのsudo設定から調べ始めないようにします。MID Server側のログは導入ディレクトリや権限に依存するため、製品資料と運用手順で所在を確認します。ログに機密が含まれる可能性があるので、必要な範囲だけ参照します。T12
以下はすべて確認用の例です。ただし、通信コマンドは接続先に記録を残し、認証操作はロックアウトの原因にもなります。「設定を書き換えない」ことと「副作用がない」ことは同じではありません。
2. MID Server側で名前解決とTCPを確認する
管理者のPCから接続できても、MID Serverから同じ経路で接続できるとは限りません。実際に選ばれたMID Serverホストで確認します。ホスト名を使う処理については名前解決を、IP指定の処理については指定アドレスと経路を確認します。
LinuxのMID Serverホストで名前解決を見る
getent ahosts linux01.example.com
- 実行場所・前提：LinuxのMID Serverホスト。glibc系のgetentが利用可能で、対象を確認する権限があること
- 目的・見る点：OSの名前解決経路で得られるアドレスを、想定する対象と比較する。複数行はソケット種別等の違いであり、すべて別サーバーとは限らない
- 限界：DNSだけの検査ではない。hostsファイルやNSS（Name Service Switch、名前情報の参照先を切り替える仕組み）設定も影響する。解決成功だけでSSH到達・認証成功は分からない
- 注意・根拠：設定変更はしないが問い合わせは発生し得る。実際のアドレスは外部へ貼らない。Linux man-pagesおよびglibcの資料を参照 T24 T25
WindowsのMID ServerホストでDNSとTCPを見る
Resolve-DnsName -Name linux01.example.com
Test-NetConnection -ComputerName linux01.example.com -Port 22 -InformationLevel Detailed
- 実行場所・前提：WindowsのMID ServerホストのPowerShell。DnsClient／NetTCPIPモジュールと各コマンドが利用可能なこと
-
目的・見る点：1行目は名前の解決結果とレコード種別を確認。2行目は解決された宛先と
TcpTestSucceededを確認する - 限界：TCP接続成功はSSHの認証成功を示さない。名前解決の補助動作は設定・オプションに依存するため、DNS結果とアプリケーションの挙動を同一視しない
- 注意・根拠：22は既定ポートの例。対象の実際のポートに合わせる。2行目は対象へ実際に接続する。経路・送信元等の出力は非公開で扱う。Microsoft公式資料を参照 T31 T32
Linux側では次節のSSH詳細出力を、到達・ハンドシェイク・認証を分ける材料にできます。TCP専用ツールを追加する場合は、ディストリビューションごとの実装やオプションを確認してください。
pingの成否だけでSSH可否を判定しません。pingで使うICMP（Internet Control Message Protocol）と、SSHが使うTCPのポートは別の確認対象です。ICMPが制限されていてもSSHが通る場合があり、その逆もあります。この切り分けはプロトコルの違いに基づく判断です。T20 T21 T32
3. 手動SSHは条件を限定して使う
最初に、Discoveryで利用されるCredentialのユーザー名、認証方式、接続先、ポートを確認します。秘密鍵やパスワードを画面コピーや記事へ含めません。鍵の形式や利用条件は、ServiceNow側の対応仕様も確認します。T08
次は、すでにホスト鍵を信頼済みで、事前設定済みの鍵などによる非対話SSHを調べる場合のOpenSSHクライアント例です。
ssh -v -S none -p 22 -o ConnectTimeout=5 -o ConnectionAttempts=1 -o BatchMode=yes -o StrictHostKeyChecking=yes discovery_user@linux01.example.com id
- 実行場所・前提：OpenSSHクライアントがあるMID Serverホスト。許可された対象・ユーザー・鍵を使い、ホスト鍵を管理手順で照合済みであること
-
目的・見る点：詳細出力で、名前解決・TCP接続・SSHの初期交渉・認証のどこまで進んだかを見る。成功すると対象で
idを実行し、ユーザー情報を返して接続を終了する。この例だけで対象Linuxの対話セッションが開いたままになるわけではない -
オプションの意味：
-vは詳細出力、-S noneは既存SSH接続の共有を使わない指定、-pはポート指定。BatchMode=yesはパスワードなどの対話入力を抑止するが、認証方式を公開鍵だけに固定するものではない。StrictHostKeyChecking=yesは未登録・変更されたホスト鍵を安易に受け入れない -
時間・回数の限界：
ConnectTimeout=5は接続や初期ハンドシェイク・鍵交換に関わる制限で、処理全体を5秒で終了させる指定ではない。ConnectionAttempts=1は接続試行回数で、認証試行が必ず1回という意味ではない -
判定の限界：パスワード認証の可否はこの例では判断できない。ホスト鍵未登録でも失敗する。
-S noneを付けても、手動実行ユーザーのSSH設定、SSH agentが持つ鍵、踏み台・プロキシなどの設定は残る。手動OpenSSHとMID Server内部のSSH実装や実行環境は異なるため、同じホスト上で成功してもDiscovery全体の成功証明にはならない - 注意・根拠：鍵を管理するSSH agent等の複数鍵が提示される場合がある。反復実行せず、認証失敗回数の制約を確認する。出力にはアカウント名・パス等が含まれ得る。OpenSSH公式資料を参照 T20 T21
ホスト鍵の不一致が出た場合は、接続先間違い、正当な再構築、想定外の変更などを区別します。管理者から正しい指紋を別経路で確認するまで進めません。安全確認の代わりにホスト鍵検証を無効にしたり、保存済みの鍵を無条件に消したりしないでください。
4. 認証後のユーザーと権限を確認する
SSHに成功したら、実際にどのユーザー・グループで動いているかを確かめます。前節の末尾 id 付きSSHは接続が終了するため、以下は別途確保した対象Linuxの許可されたセッションで実行する例です。MIDホストのプロンプトへ続けて入力すると、MIDホスト側の情報を調べてしまいます。
id
groups
- 実行場所・前提：対象Linux上の、Discoveryと同じ接続ユーザーの許可されたセッション。GNU coreutils系を想定
-
目的・見る点：
idでユーザーID・グループID等、groupsで現在のグループ所属を確認する - 限界：グループに入っていても、個別ファイルへのアクセスやsudo許可が保証されるわけではない。現在のセッションと新規ログイン後で所属の反映が異なる場合もある
- 注意・根拠：設定変更は行わない。ユーザー名・グループ名は内部情報として扱う。GNU coreutils公式資料を参照 T26 T27
外部ディレクトリ連携が使われる環境では、ユーザー情報の取得経路や認証・アカウント制御も関わります。ただし、すべてのMID Server利用環境にこれらが必要という意味ではありません。導入の有無が分からない状態で、連携設定の変更に進まないようにします。
5. sudoは許可リストと実際の処理を照合する
sudo -n -l
- 実行場所・前提：対象Linux上の、Discoveryと同じ接続ユーザーの許可されたセッション。sudoが導入されていること
-
目的・見る点：
-lで許可されている操作を表示し、対象ユーザー、実行ファイルのパス、引数の制約等を確認する。-nは対話入力を要求せず、必要な認証を満たせない場合に終了する - 限界：一覧表示自体の認証条件と、特定コマンドの認証条件は異なり得る。認証キャッシュも影響する。失敗しても「何も許可されない」とは限らず、成功しても必要なすべてのコマンドが実行できる証明にはならない
- 注意・根拠：権限の一覧は非公開で扱う。この確認では特権コマンドを実行しない。sudo公式資料を参照 T22 T23
一覧と、失敗したPatternやプローブが実行しようとした処理を照合します。「実行ファイルがない」「パスが異なる」「指定引数が許可条件と合わない」「非対話で必要な認証を満たせない」を分けて記録します。シェル環境やPATH（実行ファイルの検索先）の違いも確認対象ですが、対話シェルの設定をそのままDiscoveryへ当てはめないようにします。
ServiceNowの特権コマンド資料は照合の出発点です。権限追加が必要なら、理由と限定した範囲を管理者へ提示します。対象での追加テストや変更は承認された検証計画で行い、本記事の確認だけを根拠に広い権限を追加しません。T09
6. Linuxのサービスとログを同じ時刻で読む
systemdを使う環境では、次のようにSSHサービスの状態を参照できます。該当するユニット名の1行だけを選びます。
# sshd.serviceを使う環境の例
systemctl status sshd.service --no-pager
# ssh.serviceを使う環境の例
systemctl status ssh.service --no-pager
- 実行場所・前提：対象Linux。systemdがPID 1（最初のユーザー空間プロセス）として使われ、実際のSSHユニット名を確認済みであること
- 目的・見る点：ロード状態、Active状態、最近のメッセージを見る。sshd.serviceを使う構成がある一方、Ubuntuの公式資料ではssh.serviceが使われる。実際のユニット名と構成を優先する
- 限界：Active表示だけで、目的のポート・アドレスで待受していることや、対象ユーザーの認証成功までは証明できない。ユニット不在や非稼働時には終了ステータスが非ゼロになり得る
- 注意・根拠：表示に権限が必要な場合がある。サービスの再起動や設定変更は行わない。systemdおよびLinuxベンダー公式資料を参照 T29 T33
次はログの範囲を絞る書式です。日時は意図的に未記入で、このまま実行するコマンドではありません。YYYY-MM-DD HH:MM:SS を調査対象の開始・終了日時に置き換え、SSHユニット名も実環境に合わせます。
journalctl -u sshd.service --since 'YYYY-MM-DD HH:MM:SS' --until 'YYYY-MM-DD HH:MM:SS' --no-pager
- 実行場所・前提：対象Linux。systemd-journaldが利用され、閲覧権限と対象期間のログがあること
-
目的・見る点：
-uはユニット、--since／--untilは期間、--no-pagerはページャーを使わない指定。ServiceNow側の失敗時刻・ユーザー・接続元と対応する記録を探す - 限界：タイムゾーンを省略した日時の解釈、時計ずれ、保存期間、転送・永続化設定に注意する。ログが見えないことから通信がなかったとは断定しない。SSHの認証ログが別経路へ記録される構成もある
- 注意・根拠：ローカル時刻とServiceNowの表示時刻を合わせ、必要なら日時に明示的なタイムゾーンを付ける。ログには個人情報や内部構成が含まれ得るため公開しない。systemd公式資料を参照 T28 T30
ファイル型の認証ログの場所もディストリビューションやログ設定に依存します。特定のログパスが必ず存在すると決めつけず、管理者が定めた記録先を確認してください。
7. 収集後の問題はServiceNow側の結果へ進む
手動SSHと必要な権限に問題が見当たらない場合は、Discoveryの実行結果、該当Patternまたはプローブの処理結果、MID Serverのログを確認します。必要に応じてECC Queueで指示と結果の対応を調べます。outputはインスタンスからMID Server、inputはMID Serverからインスタンスという論理方向です。T02 T03 T12
「情報が返った」後にも、解析、CIの識別、CMDBの更新という確認が残ります。IRE（Identification and Reconciliation Engine、識別と調整のエンジン）関連のエラー、必要な識別属性、対象CIクラスや更新結果を確認します。画面の名称・入口はリリースやロールに依存するため、手元の環境の公式手順に合わせます。T04 T05 T06 T07
調査のためにECCレコードを編集・再投入したり、Patternの本番実行を繰り返したりする操作は、この確認手順には含めません。
8. 症状から次の確認を選ぶ
以下の英語表記は一般的なメッセージ例で、実在のログではありません。メッセージだけで原因を一つに決めつけないための表です。
| 症状 | 主な仮説 | 次に照合する証拠 |
|---|---|---|
| タイムアウト | 経路、宛先、ポート、フィルタ、初期交渉等 | MID側の解決先・経路と、失敗した段階 |
| Connection refused | 待受なし、ポート違い、能動的な拒否等 | 宛先・設定ポート、対象のサービス状態 |
| Permission denied | 接続ユーザー、認証方式、鍵、アカウント制約等 | Credential条件と対象側の認証記録 |
| ホスト鍵の不一致 | 宛先違い、再構築、想定外の鍵変更等 | 管理者が別経路で確認した正しい指紋 |
| sudoでパスワード要求 | 実行・一覧表示の認証条件、キャッシュ差等 | sudoポリシーと非対話実行の条件 |
| 一部コマンドがない／失敗 | 未導入、パス・引数差、権限、対象非対応等 | 実際の処理とOS・Pattern対応条件 |
| 手動SSHだけ成功 | Credential選択、SSH実装、鍵、実行環境の差等 | Discoveryが使った条件と手動条件の差 |
| 収集後にCIが更新されない | 解析、識別情報、更新ルール、処理エラー等 | 収集結果と識別・更新のエラー |
9. 調査結果を引き継げる形にする
空欄には、実際に観察できた事実だけを書きます。「未確認」と「失敗」を区別し、仮説は観察結果と別に残します。
| 確認箇所 | 実行・確認場所 | 観察結果 | 次の対応 | 確認日時・タイムゾーン |
|---|---|---|---|---|
| MID状態・該当実行 | ServiceNow | |||
| 名前解決・TCP | 選択されたMIDホスト | |||
| SSH認証 | MIDと対象Linux | |||
| ユーザー・sudo | 対象Linux | |||
| SSHサービス・ログ | 対象Linux | |||
| 収集・識別・反映 | ServiceNow |
この表に、調査対象・実行識別情報を組織内で安全にひも付けて保存します。問題を急いで直すときほど、設定変更の前に「どの段階で、何を根拠に止まったと判断したか」を残すと、再調査や引き継ぎに役立ちます。
参考資料
出典の確認日はすべて2026-10-07。コマンドの検証範囲は冒頭に記載したとおりです。各環境の導入版のマニュアルと照合してください。
ServiceNowのリリース省略URLは表示版が変わり得るため、参照したAustralia版の公式GitHub資料へリンクしています。これらはブランチ固定で、将来の更新まで不変ではありません。OS系の資料は下記の参照版であり、導入版の動作を保証しません。
- T02 — The ECC queue for Discovery（ServiceNow Australia）
- T03 — MID Server ECC Queue（ServiceNow Australia）
- T04 — Horizontal discovery process flow with probes and sensors（ServiceNow Australia）
- T05 — Patterns and horizontal discovery（ServiceNow Australia）
- T06 — Horizontal discovery process flow with patterns（ServiceNow Australia）
- T07 — Exploring CMDB Identification and Reconciliation（ServiceNow Australia）
- T08 — SSH credentials（ServiceNow Australia）
- T09 — MID Server privileged commands（ServiceNow Australia）
- T11 — MID Server heartbeat（ServiceNow Australia）
- T12 — Resolving MID Server issues（ServiceNow Australia）
- T20 — ssh(1)（OpenBSD-current）
- T21 — ssh_config(5)（OpenBSD-current）
- T22 — sudo(8)（sudo 1.9.17p2・公式ソース）
- T23 — sudoers(5)（sudo 1.9.17p2・公式ソース）
- T24 — getent(1)（Linux man-pages 6.19）
- T25 — NSS Configuration File（GNU libc 2.43）
- T26 — GNU Coreutils manual — id（公式現行マニュアル・id節は検索抽出で確認）
- T27 — groups invocation（GNU Coreutils・検索抽出で確認）
- T28 — journalctl(1)（systemd v257・公式ソース）
- T29 — systemctl(1)（systemd v257・公式ソース）
- T30 — systemd.time(7)（systemd v257・公式ソース）
- T31 — Resolve-DnsName（Microsoft Learn・Windows Server 2025表示）
- T32 — Test-NetConnection（Microsoft Learn・Windows Server 2025表示）
- T33 — OpenSSH server（Ubuntu Server・現行資料）