アクセス許可と所有権の問題による Azure Linux VM での SSH 接続の問題のトラブルシューティング。
適用対象: ✔️ Linux VM
Note
この記事で参照されている CentOS は Linux ディストリビューションであり、EOL (End Of Life) に到達します。 適宜、使用と計画を検討してください。 詳細については、「 CentOS End Of Life ガイダンスを参照してください。
この記事では、RHEL の /var/empty/sshd ディレクトリが原因で、Secure Shell (SSH) 経由で Linux 仮想マシン (VM) に接続できない問題の解決策を示します。 SUSE の /var/lib/empty ディレクトリ、または Ubuntu の /var/run/sshd ディレクトリが存在しないか、ルート ユーザーが所有していないか、グループ書き込み可能またはワールド書き込み可能です。
現象
SSH 経由で Linux 仮想マシン (VM) に接続すると、接続は失敗します。 Linux ディストリビューションによっては、影響を受けるディレクトリに関する次のエラー メッセージが表示される場合があります。
sudo tail /var/log/messages
sshd: /var/empty/sshd must be owned by root and not group or world-writable.
原因
この問題は、影響を受けるディレクトリがルート ユーザーによって所有されていない場合、またはグループ書き込み可能またはワールド書き込み可能な場合に発生する可能性があります。
この問題を解決するには、次のいずれかの解決策を使用します。
解決策 1: VM をオンラインで修復する
VM をオフラインで修復するには、次の 2 つの方法があります。
シリアル コンソールの使用
ローカル管理者アカウントとそれに対応する資格情報またはパスワードを使用して VM にサインインします。
次のコマンドを実行して、アクセス許可と所有権の問題を解決します。
sudo mkdir -p /var/empty/sshd sudo chmod 755 /var/empty/sshd sudo chown root:root /var/empty/sshd
"コマンドの実行" 拡張機能を使用する
Note
この方法は、Azure Linux VM エージェント (waagent) に依存します。 そのため、エージェントが VM にインストールされていることと、そのサービスが実行されていることを確認します。
Azure portal で VM の Properties ウィンドウを開き、エージェントの状態を確認します。 エージェントが有効で、 Ready 状態の場合は、次の手順に従ってアクセス許可を変更します。
Azure portal に移動し、VM の設定を見つけて、Operations で Run Command を選択します。
RunShellScript>Run を選択して、次のシェル スクリプトを実行します。
#!/bin/bash #Script to change permissions on a file mkdir -p /var/empty/sshd;chmod 755 /var/empty/sshd;chown root:root /var/empty/sshd
- スクリプトの実行が完了すると、出力コンソール ウィンドウに "成功を有効にする" というメッセージが表示されます。
SSH 経由で VM に接続でき、実行コマンド スクリプトの実行の詳細を分析する場合は、/var/log/azure/run-command ディレクトリ内のhandler.log ファイルを調べます。
解決策 2: VM をオフラインで修復する
Note
- VM のシリアル コンソール アクセスが利用できないのに waagent の準備ができていない場合は、この解決策を使用します。
- Ubuntu では、 /var/run/sshd ディレクトリはメモリ内で実行されます。 VM を再起動すると、問題も解決します。 そのため、Ubuntu VM でのオフライン トラブルシューティングは必要ありません。
VM をオフラインで修復するには、次の 2 つの方法があります。
Azure Linux 自動修復 (ALAR) を使用する
Azure Linux Auto Repair (ALAR) スクリプトは、Azure 仮想マシンの修復コマンドを使用して Linux VM を修復する で説明されている VM 修復拡張機能の一部です。
手動オフライン プロセスを自動化するには、次の手順に従います。
Note
次の手順では、それに応じて、 $RGNAME
、 $VMNAME
、 $USERNAME
、 $PASSWORD
、および repairdiskcopy
の値を置き換えます。
az vm repair create コマンドを使用して、修復 VM を作成します。 修復 VM には、問題のある VM の OS ディスクのコピーがアタッチされています。
az vm repair create --verbose -g $RGNAME -n $VMNAME --repair-username $USERNAME --repair-password $PASSWORD --copy-disk-name repairdiskcopy
修復 VM にサインインします。 OS ディスクのアタッチされたコピーのファイルシステムにマウントして chroot します。 詳細な chroot の手順に従います。
次のコマンドを実行して、アクセス許可と所有権の問題を解決します。
mkdir -p /var/empty/sshd chmod 755 /var/empty/sshd chown root:root /var/empty/sshd
変更が適用されたら、次の
az vm repair restore
コマンドを実行して、元の VM との OS ディスクの自動スワップを実行します。az vm repair restore --verbose -g $RGNAME -n $VMNAME
手動メソッドを使用する
シリアル コンソールと ALAR アプローチの両方が適用されない場合、または失敗した場合は、修復を手動で実行する必要があります。 OS ディスクを復旧 VM に手動で接続し、OS ディスクを元の VM にスワップし直すには、次の手順に従います。
OS ディスクが復旧 VM に正常にアタッチされたら、詳細な chroot の手順に従って 接続された OS ディスクのファイルシステムにマウントして chroot します。 次に、「 Azure Linux Auto Repair (ALAR) の使用」セクションの手順 3 に従って、アクセス許可と所有権の問題を解決します。
お問い合わせはこちらから
質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。