문제의 원인
다음을 사용하여 '.hgignore'와 같은 숨겨진 파일에 그룹 쓰기 권한을 추가하려고 했습니다.
#비밀번호 /고르다 # sudo chmod -R g+w .*
문제는 '..'가 이 패턴과 일치하고 이제 전체 RHEL 파일 시스템에 g+w가 설정되어 있다는 것입니다. 즉각적인 문제는 다음과 같습니다.
- /etc/sudoers를 460이 아닌 440으로 설정해야 하므로 이제 사용자는 sudo를 사용할 수 없습니다.
- 위와 유사한 메커니즘은 SSH 액세스를 허용하지 않습니다. (원격 SSH 클라이언트는 "ssh_exchange_identification: 원격 호스트에 의해 연결이 닫혔습니다." 오류 메시지를 수신합니다.)
질문
원격으로 로그인할 수 있는 기능을 다시 얻으려면 서버에 물리적으로 액세스할 수 있는 사람에게 시스템 문제 해결 방법을 교육해야 합니다.
ssh이제 문제는 복원 및 기능을 위해 권한을 되돌려야 하는 중요한 파일 및 디렉터리는 무엇입니까 sudo?
'중복으로 종료됨'에 대한 참고사항
질문"chmod -R 777 /"이 파괴적인 이유는 무엇입니까?재귀적으로 권한을 확장하면 어떤 영향을 미칠 수 있는지 자세히 설명합니다. 이 질문은 보다 광범위한 복원 및 복구를 수행할 수 있도록 SSH를 통해 원격 액세스를 다시 얻는 방법에 대한 질문에 대답하기 위한 것입니다.
답변1
패키지의 일부인 파일의 경우 다음을 수행하여 무엇이 엉망인지 확인할 수 있습니다.
rpm -- "패키지 이름" 확인
여기서 packagename은 개별 패키지이거나 "rpm -qa"의 출력을 반복할 수 있습니다.
그런 다음 rpm을 사용하여 다음과 같이 문제를 해결할 수 있습니다.
rpm --setperm "패키지 이름"
답변2
ssh 문제는 /etc 바로 아래에만 국한되지 않으며 부적절한 권한을 가지고 연결하려는 사용자의 .ssh 폴더와도 관련이 있습니다. 일반적으로 사용자의 .ssh 폴더는 700, 개인 키는 600, 그 외 모든 항목은 644가 될 수 있습니다.
/etc/ssh 폴더는 755여야 하고, /etc/ssh 아래의 개인 키는 600이어야 하며, 그 밖의 모든 항목은 644여야 합니다.
/etc의 잘못된 권한으로부터 서버를 복구하는 방법은 무엇입니까?
아마도 가장 쉬운 방법 중 하나는 백업에서 복원하는 것일 수 있습니다. 백업을 만들고 복원 절차를 테스트했습니까? :)
복원을 수행하는 데 사용할 수 있는 백업이 없는 경우 VM에서 동일한 클린 시스템을 설정한 다음 두 시스템을 비교하여 서버를 기반으로 호스트에 대한 권한을 수정해야 할 수 있습니다.
답변3
알려진 양호한 서버가 있는 경우 양호한 서버에서 다음과 같은 작업을 실행하면 서버를 복원하는 데 도움이 될 수 있습니다. (재귀적 글로빙 기능(zsh)을 가정하고 대신 -exec / xargs와 함께 find를 사용할 수 있습니다):
for i in /etc/**/*; do
perm=$(stat "$i" -c "%a")
ssh root@badServerHostName "chmod $perm $i"
done
다른 것을 제외하기 위한 몇 개의 하위 디렉토리일 수도 있습니다. 가능하다면 Rsync가 더 좋을 것입니다.오직권한이 있지만 그럴 수는 없을 것 같아요.
답변4
백업이 있고 LVM과 충분한 공간이 있는 경우 다음을 수행할 수 있습니다.
1. 백업을 새로운 임시 lv로 복원합니다(/oldperm 아래에 마운트).
2. 다음 의사 코드와 같은 작업을 수행합니다.
foreach oldfile in /oldperm/* {
newf = strip "/oldperm" from oldfile
chmod --reference=oldfile newf
}
공간 문제가 있는 경우 먼저 /etc 아래의 모든 항목처럼 부분적으로 복원할 수 있습니다. 이 트릭은 다른 파일을 템플릿으로 사용하고 권한 측면에서 인수를 일치시키는 chmod의 플래그 --reference에 의존합니다.
이렇게 하면 파일 내용을 변경하지 않고 이전 권한만 복원할 수 있습니다.