如何在變更執行個體的 sshd_config 檔案後使用 SSH 存取我的 EC2 執行個體？

簡短說明

變更執行個體的 sshd_config 檔案可能造成透過 SSH 連線時出現連線被拒錯誤。

若要確認您因連線被拒錯誤而無法存取執行個體，請在啟用詳盡訊息的情況下透過 SSH 存取執行個體。請參閱以下範例：

$ ssh -i "myawskey.pem" ec2-user@ec2-11-22-33-44.eu-west-1.compute.amazonaws.com -vvv

此範例透過 DNS 名稱連線，並使用 myawskey.pem 作為私密金鑰檔案，並以 ec2-user 作為使用者名稱。請以您的金鑰檔案和使用者名稱取代該範例的金鑰檔案和使用者名稱。

下列範例輸出顯示連線被拒的錯誤訊息：

OpenSSH_7.9p1, LibreSSL 2.7.3
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 48: Applying options for *
debug1: Connecting to ec2-11-22-33-44.eu-west-1.compute.amazonaws.com port 22.
ssh: connect to host ec2-11-22-33-44.eu-west-1.compute.amazonaws.com port 22: Connection refused

解決方法

**注意：**如果您正在使用 Nitro 型執行個體，則該裝置名稱會與下列步驟中提供的範例不同。例如，Nitro 型執行個體上的裝置名稱為 /dev/nvme，而不是 /dev/xvda 或 /dev/sda1。如需詳細資訊，請參閱 Linux 執行個體上的裝置名稱。

方法 1： 使用 EC2 序列主控台

如果您已啟用適用於 Linux 的 EC2 序列主控台，則可以使用它來疑難排解支援的 Nitro 型執行個體類型。序列主控台可協助您疑難排解開機問題、網路組態和 SSH 組態問題。序列主控台可連線至您的執行個體，無需可運作的網路連線。使用 Amazon EC2 主控台或 AWS Command Line Interface (AWS CLI) 存取序列主控台。

使用序列主控台之前，請先在帳戶層級授予對主控台的存取權。然後，建立 AWS Identity and Access Management (AWS IAM) 政策，授予 IAM 使用者存取權限。此外，每個使用序列主控台的執行個體都必須包含至少一個密碼型使用者。如果您的執行個體無法連線，而且您並未設定序列主控台的存取權限，請依照方法 2 一節中的指示進行： 使用救援執行個體。如需設定適用於 Linux 的 EC2 序列主控台的詳細資訊，請參閱設定 EC2 序列主控台的存取權限。

**注意：**如果您在執行 AWS CLI 命令時收到錯誤訊息，請確認您使用的是最新版本的 AWS CLI。

方法 2： 使用救援執行個體

警告：

• 如果您的執行個體是由包含資料的執行個體儲存體支援，或具備包含資料的執行個體儲存體磁碟區，則當您停止該執行個體時就會資料遺失。如需詳細資訊，請參閱判斷您的執行個體的根裝置類型。
• 如果您的執行個體屬於 Amazon EC2 Auto Scaling 群組的一部分，則停止執行個體可能會終止該執行個體。您使用 Amazon EMR、AWS CloudFormation 或 AWS Elastic Beanstalk 啟動的執行個體可能是 AWS Auto Scaling 群組的一部分。在這種情況下，執行個體終止取決於您 Auto Scaling 群組的執行個體縮減保護設定。如果您的執行個體屬於 Auto Scaling 群組的一部分，請先暫時從 Auto Scaling 群組移除該執行個體，然後再開始進行解決方法的步驟。
• 停止和啟動執行個體會變更您執行個體的公有 IP 地址。如果您不希望在重新啟動或終止執行個體時變更您的 EC2 公有 IP 地址，請使用彈性 IP 地址。如果您使用 Amazon Route 53，您可能必須在公有 IP 地址變更時更新 Route 53 DNS 記錄。

1.    在您的虛擬私有雲端 (VPC) 中啟動新的 EC2 執行個體。在與受損執行個體相同的可用區域 (AZ) 中使用相同的 Amazon Machine Image (AMI)。新的執行個體會變成您的救援執行個體。

2. 停止受損的執行個體。

3. 將 Amazon Elastic Block Store (Amazon EBS) 根磁碟區 (/dev/xvda 或 /dev/sda1) 從受損的執行個體中分離。

4. 將 EBS 磁碟區做為次要裝置 (/dev/sdf) 附加至救援執行個體。

5. 使用 SSH 連線至您的救援執行個體。

6. 執行 lsblk 命令以檢視裝置：

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk
└─xvda1 202:1    0   8G  0 part /
xvdf    202:80   0   8G  0 disk
 └─xvdf1 202:81   0   8G  0 part

7. 在步驟 4 中，為您附加至救援執行個體的新磁碟區建立一個掛接點目錄 (/rescue)：

$ sudo mkdir /mnt/rescue

8. 將磁碟區掛接至您在步驟 7 中建立的目錄：

$ sudo mount -t xfs -o nouuid /dev/xvdf1 /mnt/rescue/

若要掛接 ext3 和 ext4 檔案系統，請執行下列命令：

$ sudo mount /dev/xvdf1 /mnt/rescue

**注意：**前述掛接命令的語法可能會有所不同。如需詳細資訊，請執行 man mount 命令。

9. 再次執行 lsblk 命令，以便驗證該磁碟區是否已掛接該目錄：

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk
└─xvda1 202:1    0   8G  0 part /
xvdf    202:80   0   8G  0 disk
└─xvdf1 202:81   0   8G  0 part /mnt/rescue

更正或複製 sshd_config 檔案

您可以檢查受損執行個體上的 sshd_config 檔案，並復原變更 (如有需要)。使用 SSH 詳盡訊息輸出，引導您找到檔案中的錯誤位置：

$ sudo vi /mnt/rescue/etc/ssh/sshd_config

或者，執行下列命令，將 sshd_config 檔案從救援執行個體複製到您的受損執行個體。此命令會取代原始執行個體上 sshd_config 檔案的內容：

$ sudo cp /etc/ssh/sshd_config /mnt/rescue/etc/ssh/sshd_config

將磁碟區重新附加至原始執行個體並測試連線

注意：如果您使用方法 2： 使用救援執行個體，然後完成下列步驟。

1. 執行 umount 命令以卸載該磁碟區：

$ sudo umount /mnt/rescue/

2. 將次要磁碟區從救援執行個體分離，然後將該磁碟區作為 /dev/xvda (根磁碟區) 附加至原始執行個體。

3. 啟動該執行個體。

4. 透過 SSH 連線至執行個體，以便驗證您可以連線至該執行個體。

相關資訊

為什麼我無法透過 SSH 連接至我的 Amazon EC2 Linux 執行個體？