보안팀이 사용자가 authorized_keys를 마음대로 고치지 못하게 하려고, 키 파일을 홈 디렉터리 대신 /etc/ssh/authorized_keys/<사용자> 로 모아 관리하도록 바꿨습니다. 파일은 root 소유에 권한 600으로 배포했습니다. 적용 직후부터 배포 계정을 포함해 모든 사용자의 SSH 키 로그인이 거부됩니다. 키 내용은 이전과 똑같습니다. 다행히 콘솔 접속은 됩니다. 담당자는 키 형식이 새 위치와 맞지 않는 것 같다며 키를 다시 만들라고 공지하려 합니다.
SSH 키를 한곳에 모아 관리하기 시작한 뒤 모든 키 로그인이 거부됨
보안팀이 사용자가 authorized_keys를 마음대로 고치지 못하게 하려고, 키 파일을 홈 디렉터리 대신 /etc/ssh/authorized_keys/<사용자> 로 모아 관리하도록 바꿨습니다.
시나리오
단서
sshd[3120]: Could not open user 'deploy' authorized keys '/etc/ssh/authorized_keys/deploy': Permission denied sshd[3120]: Connection closed by authenticating user deploy 10.20.3.14 port 51220 [preauth]
$ grep AuthorizedKeysFile /etc/ssh/sshd_config AuthorizedKeysFile /etc/ssh/authorized_keys/%u $ ls -l /etc/ssh/authorized_keys/deploy -rw------- 1 root root 402 Sep 27 09:40 /etc/ssh/authorized_keys/deploy
과제 원인을 좁히고, 서비스를 되살리는 순서(검증 포함)와 재발 방지책을 적어 보세요.
구독하면 이어서 볼 수 있어요
이 문제의 전체 시나리오와 점검 체크리스트, 복구 순서, 모범 풀이는 Pro 구독에서 열립니다.
먼저 볼 것
- sshd가 authorized_keys를 누구의 권한으로 읽는지
- 잠그는 것(쓰기 금지)과 읽지 못하게 하는 것의 차이
점검 체크리스트
- sshd 로그의 거부 이유
- AuthorizedKeysFile 경로와 실제 파일의 소유자·모드
- sshd -T 로 최종 설정 확인
복구와 재발 방지
같이 보면 좋은 질문
현장에서 본 비슷한 케이스
0/10