这太奇怪了 以用户“g”的身份login到Linux（RHEL）框，并执行ls -lah节目
drwxrwxrwx 6 gg 4.0K Jun 23 13:27 . drwxrw-rx 6 root root 4.0K Jun 23 13:15 .. -rwxrw---- 1 gg 678 Jun 23 13:26 .bash_history -rwxrw---- 1 gg 33 Jun 23 13:15 .bash_logout -rwxrw---- 1 gg 176 Jun 23 13:15 .bash_profile -rwxrw---- 1 gg 124 Jun 23 13:15 .bashrc drw-r----- 2 gg 4.0K Jun 23 13:25 .ssh
因此，g组中的用户'g'/应该能够读写.ssh目录，但是如果我做了ls -lah .ssh/ ls: .ssh/: Permission denied 。 如果我尝试cat目录中的任何文件，我也会被拒绝
如果我以root用户身份进入，只要“用户”权限为7，就可以将权限更改为766或其他任何权限，这样就可以使用CD和LS目录和文件。
id g返回
uid=504(g) gid=506(g) groups=506(g)
我已经将这些权限完全复制到另一个相同的框中，没有问题。 我可以进入一个没有执行权限的目录。
该目录将需要设置执行位才能input它。 我不知道你testing了什么，但是你不能进入没有执行位的目录，或者读取其中的文件：
$ mkdir foo $ echo "baz" > foo/bar $ chmod 660 foo $ cd foo bash: cd: foo: Permission denied $ cat foo/bar cat: foo/bar: Permission denied
也就是说， 除非你的进程拥有CAP_DAC_OVERRIDE POSIX能力集（像root一样），它允许你在不设置可执行位的情况下input目录，iirc。
基本上，你应该尽量让你的.ssh目录在700，而其中的一切在600，只是为了安全。 ssh手册页给出了每个文件在〜/ .ssh文件所需的所有权和许可模式的说明。
目录需要执行权限才能进入。 这是预期的行为。
为了将ls或cd放入目录，您需要执行权限。 虽然你没有他们，你不能真正检查的内容，并看到里面的文件的权限，所以很可能文件权限是错误的，如果你不能猫。
目录权限700和文件权限644完全可以为我设置。
我认为这是一个ssh文件的问题呢？ 不是一般的chmod问题？
如果是这样的话
$chmod go-w ~/ $chmod 700 ~/.ssh $chmod 600 ~/.ssh/* $chmod 600 ~/.ssh/.*