Skip to content
isdnetworks
Go back

키를 넣었는데 비밀번호를 물었다

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가 홈 디렉터리와 .sshauthorized_keys의 권한을 본다고 돼 있었다. 다른 사람이 쓸 수 있는 상태면 키를 무시한다.

홈 디렉터리가 775였다. 계정을 만들 때 그룹 쓰기 권한이 붙어 있었다.

권한을 좁혔다

홈은 755, .ssh700, authorized_keys600으로 맞췄다. 소유자도 그 계정으로 바꿨다.

바로 붙었고 OpenSSH가 비밀번호를 묻지 않았다.

로그를 안 봤으면 클라이언트 쪽만 계속 뒤졌을 것이다. 실패 이유가 서버 로그에만 남는다는 것을 그때 알았다.

받는 쪽과 확인 순서

배포 대상 CentOS 서버가 여러 대라 나머지도 확인했다. 두 대가 같은 상태였다.

Bash로 짠 계정 생성 스크립트에 권한을 확인하는 줄을 넣었다. 나중에 서버를 더 넣을 때 같은 것을 또 겪지 않게 했다.

ssh -vvv/var/log/secure를 함께 보는 것이 이 문제에서는 빨랐다. 클라이언트 로그만으로는 이유가 안 나온다.

정리


Share this post on:

Previous Post
검색은 되는데 3초가 걸렸다
Next Post
코드 밖으로 꺼낸 SQL