To takie dziwne. Zalogowany do skrzynki Linuksa (RHEL) jako użytkownik „g”, robiący ls -lahpokazy

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

Więc użytkownik „g” w grupie „g” / powinien / był w stanie czytać i zapisywać w katalogu .ssh, ale jeśli to zrobię ls -lah .ssh/, dostanę ls: .ssh/: Permission denied. Otrzymuję również odmowę uprawnień, jeśli spróbuję i catjakiekolwiek pliki w katalogu

Jeśli pójdę się jako root i zmienić uprawnienia do 700, 744, 766lub cokolwiek, tak długo jak uprawnienie „użytkownik” jest 7 to działa i mogę CD i LS katalog i pliki wewnątrz.

id g zwroty

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

Edytować:

Skopiowałem te uprawnienia dokładnie do innego identycznego pudełka i nie ma problemu. Mogę cdwejść do katalogu bez uprawnień wykonywania.

Katalog będzie wymagał zestawu bitów wykonania, aby można go było wprowadzić. Nie wiem, co przetestowałeś, ale nie możesz wejść do katalogu bez bitu wykonania ani wczytać w nim plików:

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

To znaczy, chyba że twój proces ma ustawiony zestaw CAP_DAC_OVERRIDE POSIX (tak jak root ma), który pozwala ci wchodzić do katalogów bez ustawionego bitu wykonywalnego, iirc.

Zasadniczo powinieneś spróbować zachować katalog .ssh na 700, a wszystko w nim na 600, dla bezpieczeństwa. Strona podręcznika ssh zawiera instrukcje dla poszczególnych plików dotyczące wymaganych praw własności i trybów uprawnień dla plików w ~ / .ssh.

Katalog wymaga uprawnień do wykonania, aby cddo niego wejść. To jest oczekiwane zachowanie.

Aby ls lub cd do katalogu, potrzebujesz uprawnień do wykonywania. Chociaż ich nie masz, nie możesz tak naprawdę sprawdzić zawartości i zobaczyć uprawnień do plików w środku, więc najprawdopodobniej same uprawnienia do plików są błędne, jeśli nie możesz ich cat.

Uprawnienia do katalogu 700 i uprawnienia do plików 644 są dla mnie całkowicie OK.

Rozumiem, że jest to teraz problem z plikiem ssh? nie jest to ogólny problem chmod?

Jeśli tak, spróbuj

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

Katalogi wymagają zestawu bitów x (dla katalogu ten bit jest postrzegany jako bit wyszukiwania), aby otworzyć. Używam więc drzewa, aby uzyskać tylko zestaw folderów i uniknąć koszmaru ustawiania wszystkich plików jako plików wykonywalnych (opcja dla drzewa to -d List directories only.):

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

Ostrzeżenie!!! powinieneś wziąć to pod uwagę:

• użycie chmod lub chown rekursywnego w /katalogu głównym lub katalogach systemowych zniszczy Twój system operacyjny (w rzeczywistości wszystko, co rekurencyjne w /katalogu lub katalogach systemowych jest niebezpieczne)

• nie jest dobrą praktyką bezpieczeństwa ustawiać takie uprawnienia zbiorcze