故障表現
在使用 jumperver 登錄 AWS ec2 實例的時候發現 ssh 配合秘鑰登錄的時候無法登錄，
具體報錯如下：
ssh -i /path/xx.pem user@10.0.11.190
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
問題排查過程
在發現無法登錄的第一時間等了AWS 平台查看底層監控是否正常
查看到底層硬件工作正常，並沒有觀察到異常報錯。
通過查看業務服務，發現業務服務並沒有收到影響。
那就說明，服務器是沒有問題的，只是登錄認證出了問題。既然服務沒有問題，接下來就慢慢排查就，就不着急了。
接着，嘗試用 aws 的 ssm (Amazon Systems Manager)嘗試登錄，發現能夠使用 ssm 登錄。
再次回到跳板機，運行 telnet 10.0.11.190 22 端口是通的。排除網絡端口問題。
查看 ssh 登錄日志
ssh -i /path/xx.pem user@10.0.11.190 -vvv
查看 secure 日志
tail -f /var/log/secure
問題解決
經過查看日志，總結如下:
1
當前是從跳板機，以ssh的方式連接到故障主機，但是在連接過程中遇到如下所示報錯：
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
從ssh -vvv的debug日志來看，ssh client端發送了認證請求，但是ssh server端並沒有完成認證過程，導致permission denied報錯產生。
2
故障主機配置了SSM agent，並且可以通過session manager打開。
在這個基礎上，在實例的/var/log/secure文件中看到如下報錯內容：
authentication refused: bad ownership or modes for directory /home/ec2-user/
這個報錯的意思是說，/home/ec2-user/ 目錄的owner或者mode存在一些問題。
經過查看，/home/ec2-user/ 目錄配置的是777的權限，進而導致的認證失敗。
將其修改為700后，問題得到解決，可以ssh登錄到故障主機。
為什么會有777的權限呢？
為何會將 /home/ec2-user/ 目錄下所有內容修改為 777 呢？
經過登錄 Jumoserver 的審計發現，一名開發人員將 /home/ec2-user/ 權限改為了 777 原因是通過 Jumpserver 上傳文件的時候沒有權限，然后開發就自己將目錄給了 777的權限。
文章鏈接