我有一個運行正常的EC2 實例，有多個用戶，其中一些用戶被chroot 到他們的主目錄，其中一些僅ftp 並且沒有shell 訪問權限，等等... ec2-user 是主管理員帳戶，儘管其他使用者也有root 存取權和完整的 ssh 登入。一切在運行實例上運作良好。
我可以拍攝實例的快照圖像並從快照啟動新實例。無論我選擇與新執行個體關聯的金鑰對（使用 ec2-user 的原始金鑰對、建立新金鑰對或不使用金鑰對），一旦新執行個體啟動並執行，我都無法使用ec2-user 或任何其他啟用ssh 的使用者透過ssh 進入伺服器。不過 ftp 工作正常。
安全群組不是問題，據我所知，傳入流量是允許的（無論如何，它與原始實例是相同的安全群組）。
登入嘗試的 /var/log/secure 給了我：
sshd[1739]: debug1: userauth-request for user ec2-user service ssh-connection method none
sshd[1739]: debug1: attempt 0 failures 0
sshd[1738]: debug1: user ec2-user does not match group list sftponly at line 142
sshd[1738]: debug1: PAM: initializing for "ec2-user"
sshd[1738]: debug1: PAM: setting PAM_RHOST to "..."
sshd[1738]: debug1: PAM: setting PAM_TTY to "ssh"
sshd[1739]: debug1: userauth-request for user ec2-user service ssh-connection method publickey
sshd[1739]: debug1: attempt 1 failures 0
sshd[1738]: debug1: temporarily_use_uid: 500/500 (e=0/0)
sshd[1738]: debug1: trying public key file /etc/ssh/keys/ec2-user
sshd[1738]: debug1: restore_uid: 0/0
sshd[1738]: debug1: temporarily_use_uid: 500/500 (e=0/0)
sshd[1738]: debug1: trying public key file /etc/ssh/keys/ec2-user
sshd[1738]: debug1: restore_uid: 0/0
sshd[1738]: Failed publickey for ec2-user from xx.xx.xx.xx port 60597 ssh2
sshd[1739]: Connection closed by xx.xx.xx.xx
sshd[1739]: debug1: do_cleanup
對於所有啟用 ssh 的使用者來說都是相同的錯誤。正如您從日誌中看到的，我更改了原始實例上的 sshd_config，以便它在 /etc/ssh/keys 資料夾中尋找公鑰。
我已將失敗的實例作為磁碟區安裝在工作實例上。密鑰位於資料夾中，具有相同的權限和相同的密鑰值，一切都符合預期。這是金鑰資料夾 (.) 和 ec2-user 檔案的 ls -al。
drwxr-xr-x. 2 root root 4096 Dec 1 16:59 .
-rw-------. 1 ec2-user ec2-user 388 Jul 25 13:27 ec2-user
什麼可能導致這個問題？我想在儲存和啟動快照或設定原始實例時解決問題，但不安裝有問題的實例並進行手動更改，以便它可以正常工作，但不能解決更大的問題。
更新：以下是 sshd_config 檔案中的活動設定：
#...
Protocol 2
#...
SyslogFacility AUTHPRIV
LogLevel DEBUG
#...
AuthorizedKeysFile /etc/ssh/keys/%u
#...
PasswordAuthentication no
#...
ChallengeResponseAuthentication no
#...
GSSAPIAuthentication yes
#...
GSSAPICleanupCredentials yes
#...
UsePAM yes
#...
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS
#...
X11Forwarding yes
#...
Subsystem sftp internal-sftp -f AUTH -l VERBOSE
#...
Match group sftponly
ChrootDirectory /home/%u
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp -l VERBOSE -f AUTH
#...
答案1
我懷疑這是 SELinux 問題。檢查您正在使用的資料夾的上下文，我預計它不適合保存密鑰。
恐怕我無法再訪問 Redhat 盒子來準確確定上下文應該是什麼。也就是說，試試這個：
ls -lZ /root/.ssh
這將產生新資料夾所需的 selinux 上下文。如果沒記錯的話應該是類似 system_u:system_r:sshd_t
然後我們需要將該安全上下文套用到您的新授權金鑰位置：
semanage fcontext -a -t system_u:system_r:sshd_t “/etc/ssh/keys(/.*)?”
它將正確的上下文與新的鍵位置相關聯。最後，我們可以將上下文應用到新位置
restorecon -Rv /etc/ssh/keys
答案2
sshd_config 中是否設定了「AllowUsers」指令？也許它在原始伺服器上設定為特定用戶並且 ssh 尚未重新啟動，因此它仍然接受所有用戶？
哦，我剛剛在調試中看到了這一點：“用戶 ec2-user 在第 142 行與組列表 sftponly 不匹配”請檢查 sshd_config 您可能不允許使用群組，或者只允許 sftp？