共计 1062 个字符，预计需要花费 3 分钟才能阅读完成。
文章链接
故障体现
在应用 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的权限。
文章链接
