SSH サービスの起動時に "error while loading shared libraries" エラーが発生した場合の対処方法 -

問題の説明

SSH サービスが起動に失敗します。エラーメッセージは、libcrypto.so.1.1 共有ライブラリが見つからないことを示しています。

error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory.

原因

SSH サービスとその認証モジュールは、実行時に libcrypto.so.1.1 共有ライブラリを動的に読み込みます。このエラーは、ライブラリファイルまたはそのシンボリックリンクのターゲットファイルが見つからない、移動された、または破損している場合に発生します。この依存関係がないと、SSH サービスは起動できません。

解決策

重要

システムディスクの以前のスナップショットが利用可能な場合は、まず新しいスナップショットを作成して現在のデータをバックアップします。次に、以前のスナップショットを使用してシステムディスクをロールバックし、SSH サービスが正しく起動することを確認します。

以前のスナップショットが利用できない場合は、問題のあるインスタンスと同じオペレーティングシステムを実行し、同じゾーンにある正常な Elastic Compute Server (ECS) インスタンスが必要です。問題のあるインスタンスのシステムディスクを正常なインスタンスにアタッチすることで、見つからないライブラリファイルを復元できます。

ステップ 1: システムディスクをデタッチする

問題のあるインスタンスが [停止済み] 状態であることを確認してから、次のステップを実行します。

データの損失を防ぐために、システムディスクのスナップショットを作成します。
ECS コンソール - インスタンスに移動します。上部のナビゲーションバーで、対象のリージョンとリソースグループを選択します。
問題のあるインスタンスの ID をクリックして [インスタンス詳細] ページを開き、[ブロックストレージ] タブをクリックします。
[システムディスク] の [アクション] 列で、 > [デタッチ] を選択します。
[クラウドディスクのデタッチ] ダイアログボックスで、詳細を確認して [OK] をクリックします。インスタンスのステータスが [システムディスクなし] に変わると、ディスクは正常にデタッチされます。

ステップ 2: ディスクをデータディスクとして正常なインスタンスにアタッチする

正常なインスタンスが [実行中] 状態であることを確認してから、次のステップを実行します。

問題のあるインスタンスのシステムディスクを正常なインスタンスにアタッチします。
1. 正常なインスタンスの ID をクリックして、その詳細ページを開きます。
2. [ブロックストレージ] タブをクリックし、[クラウドディスクのアタッチ] をクリックします。
3. [クラウドディスクのアタッチ] ページで、[ディスク] セクションでデタッチされたシステムディスクを選択し、[次へ] をクリックします。
4. [ディスクのパーティション分割とファイルシステムの作成およびマウント] ページで、[後で設定] を選択します。
[接続] をクリックし、[Workbench] を選択します。プロンプトに従ってインスタンスにログオンし、ターミナルを開きます。

ファイルシステムをマウントします。

問題のあるディスクのパーティション名を特定します。

sudo lsblk -f

vda                                                      
├─vda1                                                   
├─vda2 vfat         7938-FA03                            /boot/efi
└─vda3 ext4   root  33b46ac5-7482-4aa5-8de0-60ab4c3a4c78 /
vdb                                                      
├─vdb1                                                   
├─vdb2 vfat         7938-FA03                            
└─vdb3 ext4   root  33b46ac5-7482-4aa5-8de0-60ab4c3a4c78

この例では、vdb が問題のあるディスクで、vdb3 がマウントするルートパーティションです。パーティションは次のとおりです。

vdb1/vdb2: システムブートファイルが含まれています。これらは無視してかまいません。
vdb3: オペレーティングシステムファイルとデータが含まれています。このパーティションはマウントする必要があります。

ディレクトリを作成し、ファイルシステムをマウントします。

sudo mkdir <mount_directory> && sudo mount /dev/<partition_name> <mount_directory>

パラメーター	説明
`<partition_name>`	前のステップで特定した問題のあるディスクのルートパーティション名。
`<mount_directory>`	`/` で始まるカスタムの空のディレクトリパス。重要空でないディレクトリにファイルシステムをマウントすると、そのディレクトリ内の元のファイルにアクセスできなくなります。

たとえば、ターゲットパーティション vdb3 を /test という名前の新しいディレクトリにマウントするには、sudo mkdir /test && sudo mount /dev/vdb3 /test を実行します。

ファイルシステムがマウントされていることを確認します。
sudo lsblk コマンドを実行します。ターゲットパーティションにマウントディレクトリ (MOUNTPOINT) が表示されれば、ファイルシステムはマウントされています。

ステップ 3: libcrypto.so.1.1 ファイルを修復する

このトピックでは、Alibaba Cloud Linux 3.2104 を例として使用します。正常なインスタンスで、マウントされたパスにある共有ライブラリファイルを修復します。

libcrypto.so.1.1 へのパスを見つけます。
ライブラリファイルの名前は、オペレーティングシステムによって異なる場合があります。特定のエラーメッセージに表示されるファイル名を検索してください。
```
sudo find / -name libcrypto.so.1.1
```
出力例:
```
/usr/lib64/libcrypto.so.1.1
```
サンプル出力は、ライブラリファイルが /usr/lib64/ ディレクトリにあることを確認します。
シンボリックリンクのターゲットを確認します。
```
ll /usr/lib64/libcrypto.so.1.1
```
出力例:
```
lrwxrwxrwx. 1 root root 19 Nov 20  2024 /usr/lib64/libcrypto.so.1.1 -> libcrypto.so.1.1.1k
```
この例は、libcrypto.so.1.1 が libcrypto.so.1.1.1k ファイルを指すシンボリックリンクであることを示しています。したがって、正常な libcrypto.so.1.1.1k ファイルを問題のあるディスクの同じパスにコピーします。
ライブラリファイルを復元します。
<mount_directory> を、作成した実際のマウントディレクトリに置き換えます。
```
sudo cp /usr/lib64/libcrypto.so.1.1.1k <mount_directory>/usr/lib64/
```
この例に基づくと、sudo cp /usr/lib64/libcrypto.so.1.1.1k /test/usr/lib64/ を実行します。
正しい権限を設定し、シンボリックリンクを再作成します。
1. ファイルの権限と所有者を設定します。
  <mount_directory> を、作成した実際のマウントディレクトリに置き換えます。
```
# Set permissions to rwxr-xr-x
sudo chmod 755 <mount_directory>/usr/lib64/libcrypto.so.1.1.1k

# Set owner and group to root
sudo chown root:root <mount_directory>/usr/lib64/libcrypto.so.1.1.1k
```
  この例に基づくと、sudo chmod 755 /test/usr/lib64/libcrypto.so.1.1.1k と sudo chown root:root /test/usr/lib64/libcrypto.so.1.1.1k を実行します。
2. シンボリックリンクを再作成します。
```
sudo ln -sf /usr/lib64/libcrypto.so.1.1.1k <mount_directory>/usr/lib64/libcrypto.so.1.1
```
  この例に基づくと、sudo ln -sf /usr/lib64/libcrypto.so.1.1.1k /test/usr/lib64/libcrypto.so.1.1 を実行します。

ステップ 4: ディスクをシステムディスクとして問題のあるインスタンスに再アタッチする

ファイルシステムをアンマウントします。
<mount_directory> を、作成した実際のマウントディレクトリに置き換えます。
```
sudo umount <mount_directory>
```
この例に基づくと、sudo umount /test を実行します。
修復されたシステムディスクをデタッチします。
1. ECS コンソールに戻り、正常なインスタンスの詳細ページに移動します。[ブロックストレージ] をクリックします。
2. 修復されたシステムディスクの [アクション] 列で、[デタッチ] をクリックします。
3. [クラウドディスクのデタッチ] ダイアログボックスで、[OK] をクリックします。
修復されたシステムディスクを元のインスタンスに再度アタッチします。
1. 問題のあるインスタンスの詳細ページに移動し、[ブロックストレージ] タブをクリックし、[クラウドディスクのアタッチ] をクリックします。
2. [クラウドディスクのアタッチ] ページで、修復されたシステムディスクを [ディスク] として選択し、[ログオン資格情報] を設定してから、[次へ] をクリックします。
3. [ディスクのパーティション分割とファイルシステムの作成およびマウント] ページで、[後で設定] を選択します。
ECS インスタンスを起動します。

ステップ 5: 結果を確認する

問題のある ECS インスタンスにログオンし、SSH サービスを再起動して正しく実行されることを確認します。

課金を停止するには、サービスが復元されたことを確認した後、正常なインスタンスを解放できます。

推奨事項

コアシステムファイルの取り扱いには注意してください: コアシステムファイルを削除、移動、または変更する前に、必ずスナップショットを作成してデータをバックアップしてください。よく知らないシステムファイルは削除しないでください。
標準的なソフトウェアインストール方法を使用する: ソフトウェアのインストールまたはアンインストールには、yum や apt などのシステムのネイティブパッケージマネージャを常に使用してください。これにより、依存関係が自動的に処理され、共有ライブラリの損傷を防ぐことができます。