ネットワークセキュリティグループ(NSG)でポート22を誤って閉じた、SSHキーを上書きしてしまった、firewalldのルールが引っかかっている——Azure上のLinux VMへのSSH接続が断たれるケースは、ベテランでも一度は経験します。
こういった緊急事態を救うのが「Azure VM Run Command(実行コマンド)」です。AzureポータルやAzure CLI(azコマンド)から、SSHポートを一切通さずにVM内でコマンドやシェルスクリプトを実行できます。
この記事では、az vm run-commandの使い方を基本から実践シナリオまで解説します。AWS Systems Manager Run Commandとの比較も含め、Linux運用者がAzureで安心して作業できる「緊急手段」の全体像を把握してください。
この記事のポイント
・az vm run-command invokeでSSHなしにLinux VM内コマンドを実行できる
・VMエージェント(WALinuxAgent)経由で動作するためNSGルールに依存しない
・スクリプトファイルを直接渡してfirewalld修正・公開鍵追加も可能
・AWS Systems Manager Run Commandとの設計の違いも実例付きで解説する
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
Azure VM Run Commandとは何か(仕組みと特徴)
Azure VM Run Commandは、Azure VMエージェント(LinuxではWALinuxAgent)を介してVMの内部でコマンドを実行する機能です。通信経路はSSHではなくAzureプラットフォーム内部(VMエージェントとAzureファブリック間のHTTPS)を使うため、NSGでポート22を完全に閉じていても問題なく動作します。実行環境は RHEL 9.4 / Ubuntu 22.04 LTS で動作確認済みです。
前提条件:
・VM上でWALinuxAgentが動作していること(Azure Marketplace イメージではデフォルトで起動済み)
・実行者に「仮想マシン共同作成者」以上のAzure RBACロールが付与されていること
・Run CommandはVMの電源オン状態でのみ実行可能(停止・割り当て解除状態では不可)
主な用途:
・SSHが繋がらない緊急時のVM操作
・複数VMへの定型スクリプト一括配布
・Azureポータルから簡易デバッグする場合
Run Commandには2種類あります。
| 種別 | 特徴 | タイムアウト |
|---|---|---|
| アクションRunCommand(旧来型) | az vm run-command invokeで即時実行。非同期対応なし | 90分(変更不可) |
| 管理RunCommand(新型) | az vm run-command createで定義して非同期実行。タイムアウト変更可 | 設定可能(最大90分) |
az vm run-commandの基本的な使い方
1. 前提:az CLIのインストールと接続確認
ローカルPCにaz CLIがなければ以下でインストールします(Ubuntu/Debian系の場合)。# Azure CLI インストール(Ubuntu/Debian) curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash # インストール確認 az version
az login # サブスクリプション確認 az account show --query "{sub:id, name:name}" -o table
2. 基本コマンド実行(RunShellScript)
最もシンプルな使い方は、--command-id RunShellScriptと--scriptsにコマンド文字列を渡す形です。# 例:VM内でhostnameとOSバージョンを確認する az vm run-command invoke --resource-group myRG --name myVM --command-id RunShellScript --scripts "hostname; cat /etc/os-release | head -5"
{ "value": [ { "code": "ProvisioningState/succeeded", "displayStatus": "Provisioning succeeded", "message": "Enable succeeded: [stdout] myvm-prod-01 NAME="Red Hat Enterprise Linux" VERSION="9.4 (Plow)" ID=rhel ID_LIKE=fedora VERSION_ID="9.4" [stderr] ", "time": null } ] }
[stdout]と[stderr]が分かれて返ってくるのが特徴です。messageフィールド内に改行が
として入っています。3. スクリプトファイルを渡して実行する
複数行のスクリプトは--scriptsに直接書くより、ローカルのシェルスクリプトファイルを渡す方が管理しやすいです。# ローカルにスクリプトを作成 cat > /tmp/check_sshd.sh << 'EOF' #!/bin/bash echo "=== sshd status ===" systemctl status sshd --no-pager | head -10 echo "=== sshd port ===" ss -tlnp | grep sshd echo "=== firewalld rules ===" firewall-cmd --list-all 2>/dev/null || echo "firewalld not active" EOF # ファイルをスクリプトとして渡す(--scripts の前に @ファイルパス) az vm run-command invoke --resource-group myRG --name myVM --command-id RunShellScript --scripts @/tmp/check_sshd.sh
Azure対応セミナーの詳細を見る >>
実務での活用シナリオ
1. SSH公開鍵を追加・修復する
「SSHキーを別の鍵で上書きしてしまった」「新しい管理者の公開鍵を追加したい」場面で最も頼りになるシナリオです。# 追加したい公開鍵を変数に入れる NEW_PUBKEY="ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQ... admin@pc" az vm run-command invoke --resource-group myRG --name myVM --command-id RunShellScript --scripts " # azureユーザーの authorized_keys に追加 echo '${NEW_PUBKEY}' >> /home/azureuser/.ssh/authorized_keys chmod 600 /home/azureuser/.ssh/authorized_keys echo 'done' "
2. firewalldルールを確認・修正する
firewalldの誤操作でSSHポート(22番)が閉じてしまったケースです。ポート確認のアプローチについてはLinux ポート確認の全コマンドも参考にしてください。az vm run-command invoke --resource-group myRG --name myVM --command-id RunShellScript --scripts " # 現状確認 firewall-cmd --list-all # SSHポートを恒久的に開放 firewall-cmd --permanent --add-service=ssh firewall-cmd --reload # 確認 firewall-cmd --list-services "
[stdout] public (active) target: default services: dhcpv6-client http https # ← sshが無い! success success dhcpv6-client http https ssh # ← sshが復活
3. サービスを再起動してステータスを確認する
アプリケーションサービスがクラッシュした場合に再起動して状態を確認します。az vm run-command invoke --resource-group myRG --name myVM --command-id RunShellScript --scripts " systemctl restart nginx sleep 2 systemctl status nginx --no-pager | head -15 "
AWS Systems Manager Run CommandとAzure VM Run Commandの比較
AWSからAzureに移行したエンジニア向けに、両者の設計の違いを整理します。| 比較項目 | Azure VM Run Command | AWS Systems Manager Run Command |
|---|---|---|
| エージェント | WALinuxAgent(VM標準搭載) | SSM Agent(別途インストールが必要な場合あり) |
| 認証基盤 | Azure RBACロール | IAMロール+インスタンスプロファイル |
| 複数VM一括実行 | スクリプト+ループ or AzureAutomation連携 | ターゲット指定(タグ・Resource Group)で標準対応 |
| ネットワーク要件 | Azureファブリック経由。VNet外向け通信不要 | SSMエンドポイントへのHTTPS通信またはPrivateLink |
| タイムアウト上限 | 90分(管理RunCommandでも最大90分) | デフォルト3,600秒(最大172,800秒) |
| 出力保存 | CLI/APIレスポンスに直接返却(Storageへの保存は管理RunCommand) | S3バケットへの自動保存に対応 |
| CLIコマンド | az vm run-command invoke | aws ssm send-command |
設計上の最大の違いは、AWSのSSM Run Commandが複数インスタンスへの一括配布を前提とした設計であるのに対し、AzureのVM Run Commandは基本的に1VM単位の操作を前提としている点です。複数VMへの一括配布にはAzure AutomationやBicep/Terraformとの組み合わせが現実的です。
一方、エージェントがAzure Marketplace標準イメージに最初から組み込まれている点はAzureの優位性です。AWSではSSM Agentのインストール忘れや古いバージョン起因のトラブルが発生しやすい現場もあります。
トラブルシュートとよくあるエラー
「VMがVMエージェントの準備ができていない状態です」エラー
WALinuxAgentが停止しているか、バージョンが古すぎる場合に発生します。Azureポータルから「ブートの診断」で最後のコンソール出力を確認し、VM自体が正常起動しているかを先に切り分けてください。コマンドがタイムアウトする
90分のタイムアウト制限に引っかかるケースです。長時間処理(yum update --allなど)はnohupでバックグラウンド実行してプロセスだけ起動し、結果は後で確認する迂回策が有効です。az vm run-command invoke --resource-group myRG --name myVM --command-id RunShellScript --scripts "nohup dnf update -y > /tmp/dnf_update.log 2>&1 & echo PID:$!"
cat /tmp/dnf_update.logを実行します。「The client does not have authorization」エラー
実行者のAzure RBACロールが不足しています。「仮想マシン共同作成者」または「共同作成者」ロールが対象リソースグループに付与されているかを確認してください。# 現在のロール割り当てを確認 az role assignment list --resource-group myRG --assignee $(az account show --query user.name -o tsv) --output table
stdoutが空で結果が返ってこない
スクリプト内のコマンドが終了コード0でも標準出力に何も出さなかった場合です。echo "done"のような確認用出力を必ず末尾に追加してください。また、stderrにエラー出力がないかも確認します。本記事のまとめ
| やりたいこと | コマンド |
|---|---|
| VM内でコマンドを即時実行 | az vm run-command invoke --command-id RunShellScript --scripts "コマンド" |
| ローカルスクリプトファイルを実行 | az vm run-command invoke --command-id RunShellScript --scripts @ファイルパス |
| SSH公開鍵の追加・修復 | Run Command経由で~/.ssh/authorized_keysに追記 |
| firewalldでSSHポートを再開放 | Run Commandでfirewall-cmd --permanent --add-service=sshとreload |
| 長時間処理を実行 | nohupでバックグラウンド起動→ログを後でRun Commandで確認 |
| RBACロール確認 | az role assignment list --resource-group myRG --output table |
Azure VM Run Commandは「SSH接続できない時の最後の手段」として知っておくと現場での安心感が大きく変わります。WALinuxAgentが稼働していれば、NSGやfirewalldのルールに関係なくコマンドが届くため、設定ミスや鍵の紛失でVMが孤立するリスクを大幅に下げられます。
Azure環境でのLinuxサーバー運用を体系的に学びたい方は、以下もあわせてご覧ください。
Azure対応セミナーの詳細を見る >>
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら
- 前のページへ:AzureのLinux VMとのファイル転送をどう通すか|Bastionトンネル・Azure Files・Blobの向き不向き
- この記事の属するカテゴリ:Azureへ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます