C'est tellement bizarre. Connecté à une boîte Linux (RHEL) en tant qu'utilisateur 'g', faisant un ls -lahshow

drwxrwxrwx 6 g    g    4.0K Jun 23 13:27 .
drwxrw-r-x 6 root root 4.0K Jun 23 13:15 ..
-rwxrw---- 1 g    g     678 Jun 23 13:26 .bash_history
-rwxrw---- 1 g    g      33 Jun 23 13:15 .bash_logout
-rwxrw---- 1 g    g     176 Jun 23 13:15 .bash_profile
-rwxrw---- 1 g    g     124 Jun 23 13:15 .bashrc
drw-r----- 2 g    g    4.0K Jun 23 13:25 .ssh

Ainsi, l'utilisateur 'g' dans le groupe 'g' / devrait / devrait pouvoir lire et écrire dans le répertoire .ssh mais si je le fais, ls -lah .ssh/j'obtiens ls: .ssh/: Permission denied. Je reçois également une autorisation refusée si j'essaie et catque des fichiers du répertoire

Si je vais en tant que root et changer les autorisations 700, 744, 766ou quoi que ce soit tant que l'autorisation de l'utilisateur 'est 7 cela fonctionne et je peux CD et LS le répertoire et les fichiers à l' intérieur.

id g Retour

uid=504(g) gid=506(g) groups=506(g)

Éditer:

J'ai copié ces autorisations exactement dans une autre boîte identique et il n'y a aucun problème. Je peux cddans un répertoire sans autorisations d'exécution.

Le répertoire va exiger la pour que vous puissiez exécuter bit pour y entrer. Je ne sais pas ce que vous avez testé, mais vous ne pouvez pas entrer dans un répertoire sans le bit d'exécution, ou y lire des fichiers:

$ mkdir foo
$ echo "baz" > foo/bar
$ chmod 660 foo
$ cd foo
bash: cd: foo: Permission denied
$ cat foo/bar
cat: foo/bar: Permission denied

C'est-à-dire, à moins que votre processus n'ait le jeu de capacités CAP_DAC_OVERRIDE POSIX (comme root a), qui vous permet d'entrer des répertoires sans le jeu de bits exécutables, iirc.

Fondamentalement, vous devriez essayer de garder votre répertoire .ssh à 700, et tout ce qu'il contient à 600, juste pour être sûr. La page de manuel ssh donne des instructions par fichier sur les propriétaires et les modes d'autorisation requis pour les fichiers dans ~ / .ssh.

Un répertoire nécessite une autorisation d'exécution pour y cdentrer. C'est le comportement attendu.

Pour ls ou cd dans un répertoire, vous avez besoin des autorisations d'exécution. Bien que vous ne les ayez pas, vous ne pouvez pas vraiment inspecter le contenu et voir les autorisations des fichiers à l'intérieur, donc très probablement les autorisations de fichiers sont fausses elles-mêmes, si vous ne pouvez pas les chatter.

L'autorisation de répertoire de 700 et les autorisations de fichier 644 sont parfaitement OK pour moi.

Je suppose que c'est un problème de fichier ssh maintenant? pas un problème général de chmod?

Si oui, essayez

$chmod go-w ~/
$chmod 700 ~/.ssh
$chmod 600 ~/.ssh/*
$chmod 600 ~/.ssh/.*

Les répertoires nécessitent un ensemble de x bits (pour le répertoire, ce bit est considéré comme un bit de recherche) pour s'ouvrir. J'utilise donc l'arborescence pour ne pouvoir obtenir que l'ensemble de dossiers et éviter le cauchemar d'avoir tous les fichiers définis comme exécutables (l'option pour l'arborescence est -d List directories only.):

sudo tree -faid here_goes_your_directory xargs -L1 -I{} sudo chmod 755  "{}"

Avertissement!!! vous devriez avoir ceci en considération:

• utiliser chmod ou chown récursif sur le /répertoire racine ou les répertoires système détruira votre système d'exploitation (en fait, tout ce qui est récursif sur le /répertoire ou les répertoires système est dangereux)

• ce n'est pas une bonne pratique de sécurité pour définir le volume des autorisations comme ça