IDC에 입고한 서버에 배포 스크립트를 붙이려고 SSH 공개키를 넣었다. 넣었는데도 OpenSSH가 접속할 때마다 비밀번호를 물었다.
Table of contents
Open Table of contents
키를 넣었는데 그냥 물었다
CentOS가 올라간 서버였다. ~/.ssh/authorized_keys에 공개키를 붙여 넣었고 파일을 열어 보면 내용이 들어 있었다.
그런데 ssh 하면 여전히 비밀번호 창이 떴다. 키를 다시 만들어 넣어도 같았다.
원인이 갈린 자리
같은 RSA 키로 다른 서버에는 붙었다. 그 서버만 안 됐다.
ssh -vvv로 붙어 보니 서버가 공개키를 받고 나서 다음 방식으로 넘어가고 있었다. 클라이언트는 키를 제대로 보내고 있었다.
가이드에는 어떻게 돼 있나
서버 쪽 /var/log/secure를 봤다.
Authentication refused: bad ownership or modes for directory /home/deploy
OpenSSH 문서를 찾아보니 sshd가 홈 디렉터리와 .ssh와 authorized_keys의 권한을 본다고 돼 있었다. 다른 사람이 쓸 수 있는 상태면 키를 무시한다.
홈 디렉터리가 775였다. 계정을 만들 때 그룹 쓰기 권한이 붙어 있었다.
권한을 좁혔다
홈은 755, .ssh는 700, authorized_keys는 600으로 맞췄다. 소유자도 그 계정으로 바꿨다.
바로 붙었고 OpenSSH가 비밀번호를 묻지 않았다.
로그를 안 봤으면 클라이언트 쪽만 계속 뒤졌을 것이다. 실패 이유가 서버 로그에만 남는다는 것을 그때 알았다.
받는 쪽과 확인 순서
배포 대상 CentOS 서버가 여러 대라 나머지도 확인했다. 두 대가 같은 상태였다.
Bash로 짠 계정 생성 스크립트에 권한을 확인하는 줄을 넣었다. 나중에 서버를 더 넣을 때 같은 것을 또 겪지 않게 했다.
ssh -vvv와 /var/log/secure를 함께 보는 것이 이 문제에서는 빨랐다. 클라이언트 로그만으로는 이유가 안 나온다.
정리
- 공개키를 넣어도 홈·
.ssh·authorized_keys권한이 넓으면 무시된다 - 다른 사람이 쓸 수 있는 상태면
sshd가 키를 안 받는다 - 실패 이유는 클라이언트가 아니라 서버
/var/log/secure에 남는다 ssh -vvv로 보면 키를 보내고 나서 다음 방식으로 넘어가는 것이 보인다- 홈
755·.ssh700·authorized_keys600으로 맞춘다 - 계정 생성 순서를 적어 두고 권한 확인을 넣었다