我是 Linux 和 AWS 的新手。
我sudo chmod 2770 / command
在我的 ec2 实例上运行,然后
我所做的一切都被拒绝了(即使使用 ls 或 cd)
所以我退出了连接(使用 cygwin)并尝试重新连接,但现在我得到了
权限被拒绝(publickey、gssapi-keyex、gssapi-with-mic)
我尝试设置chmod 400 my.pem
、chmod 600 my.pem
,chmod 777 my.pem
但没有任何效果。
我尝试使用之前运行正常的 进行连接。 解决方案是什么?ssh -i my.pem [email protected]
答案1
解决方案是启动一个新实例,并且永远不要再重复你所做的操作。尝试正确恢复你重置的所有权限会过于复杂2770
。
如果你在损坏的实例上有任何有价值的文件,你可以停止它,挂载它的根卷到新实例并从那里复制文件。
更新:正如 @GeraldSchneider 指出的那样,如果您没有以递归方式更改所有地方的所有权限,那么您可能会很幸运。您必须启动一个新实例并使用它将根权限修复回0755
。例如,请按照此处的说明操作:更改了 AWS EC2 防火墙规则并锁定了 ssh(代替修复防火墙执行sudo chmod 755 /mnt
或安装其他磁盘的任何地方)。
希望有帮助:)
答案2
您所做的是使文件系统中的每个文件都具有 2770 权限。
-rwxrws--- 1 username agroup 2 Feb 19 23:07 thefilename
这是组列中的粘性位,这意味着目录内的所有文件都归一个小组。
我从来没有如此严重地损坏过 AWS 映像。但我见过一些导致映像损坏的问题。
第一的 在控制文件模式之前,恢复到最后一个快照。
您不做定期快照吗?
第二查看您的备份。重建盒子的工作量与从备份中恢复数据的工作量相比是更大还是更小?
什么?你也没有备份吗?
然后最后一搏标准恢复方法如下:
- 从当前 AMI 创建新实例,最好是与损坏的机器相同的发行版。它可以是像 t3.nano 这样的小实例
- 从损坏的机器上分离卷,然后将它们作为 sdf、g、h 等附加到新实例
以 root 身份登录到新实例,并针对每个损坏实例的磁盘运行
fsck /dev/xvdX mkdir /sdX mount /dev/xvdX /sdX cd /sdX ls -l
此时你需要决定是否值得使用修改模式一遍又一遍地解决您的问题,或者将数据复制到新的实例并重新进行设置。
因此,请手动更改每个目录,并将每个文件的 chmod 设置为应有的值。保持两个窗口打开,并将实时主机的文件与安装的损坏磁盘进行比较。确保您更改了正确的文件 - 经常检查!!!
完成所有操作后,关闭临时机器,在 EC2 Web GUI 中分离磁盘,然后将它们重新连接到旧机器,并使用它们原来的安装点。注意,根驱动器连接为sda1不是星展银行 但所有其他卷都通过 z 作为 sdb 附加。
无论哪种方式,您都应该设置自动快照或备份,或两者!
为了防止自己再次执行此操作,请将 chmod 别名为
chmod --preserve-root
但这不会保护任何其他目录。
也不要仅仅出于习惯在命令前使用 sudo。