SSH 비밀번호 오류 해결 (Permission denied)

 CI/CD 작업 중에 ssh 연결에 문제가 발생했다. ci/cd 글 내에서 정리하려했지만 트러블 슈팅을 정리하다보니 글이 길어졌다. ssh 연결 관련 에러를 겪고있을 누군가를 위해서 해결하는 과정을 따로 작성했다. 

 

 해당 글은 ssh 오류를 해결하는 전 과정이 담겨있으므로 해결방법만 알고싶다면 맨 끝 부분만 읽는 것을 권장한다.

---

 

에러 1. 

서버에서 설정한 비밀번호가 맞지 않아서 Sorry, try again이 계속 나왔다.

 

해결 : 로컬 sudo 를 풀기 위한 비밀번호를 입력했다........... 즉, 터미널은 서버 비밀번호를 원한 것이 아니라 로컬 sudo를 풀기 위한 비밀번호가 필요했던 것이었다.

-> 로컬 sudo 용 비밀번호인지 모르고 왜 안되는지 모르는채로 2시간을 버렸다😩 sudo 비밀번호라는 것을 알게되었을때 그 허무함.. 어이가 없고 시간을 내다 버린 것 같은 기분이 들었다. 도대체 왜 이런 어이없는 문제에 시간을 버렸을까ㅠㅠ

---

에러 2.

Permission denied (publickey).

 

시도 1. 구글링 해보니까 pem key가 없어서 발생한 문제인 것 같았다. 그래서 sshd_config 파일에서 PasswordAuthentication 옵션을 yes로 바꾼걸 다시 확인하고, pem 키로 연결하는 옵션인 PubkeyAuthentication 을 주석처리했다. -> 안됨

시도 2(해결(?)). PubkeyAuthentication 옵션을 no 로 설정 -> Permission denied (publickey)는 없어졌지만 password가 맞지 않는 에러 발생.. 

---

에러 3. 

서버 비밀번호가 틀렸다고 나옴.

 

시도 1. 설마 내가 진짜로 비밀번호를 잘못 알고있었나라는 생각이 들었다. 그래서 pem 키로 접속한 서버에서 su ubuntu, su root를 해서 비밀번호를 확인했다. 하지만, 내가 알고있는 비밀번호가 맞았고 여전히 비밀번호 서버 접속은 안됐다.

시도 2. 또한 sshd_config에서 root 접속 허용 옵션을 안켜서 그런가 싶어서 옵션을 yes로 바꿨지만 그 역시 안됐다.

시도3. 서버의 auth log를 확인했다.  /var/log/secure, /var/log/auth.log

서버에서 해당 로그를 열어놓고 다시 로그인을 시도했더니 다음과 같은 에러가 새로 발생했다.

Apr  6 02:11:46 ip-172-31-41-62 sshd[25651]: Connection closed by authenticating user root 1.210.0.48 port 55572 [preauth] 

시도 4 : ssh 7.0 부터는 root 로그인이 아예 막혔다는 글을 확인. 그 전에 ubuntu로 접속했을 때도 안됐지만 일단 새로운 사용자를 만들어봄 -> 안됨

https://linux.systemv.pe.kr/2015/11/opensshd-7-0%ec%97%90%ec%84%9c-%eb%b0%94%eb%80%90%ec%a0%90/

Opensshd 7.0에서 바뀐점 - Voyager of Linux

시도 5. ubuntu 유저 권한 755로 바꿔봄. -> 안됨

 

중간 에러4. 갑자기 인스턴스 죽음

Operation timed out이 발생하면서 접속 자체가 안됐다. aws 들어가보니까 아예 접속이 막혔다. 

 

시도 6. 새 인스턴스를 만들어서 ssh 비밀번호 부분만 다시 해보기 

-> ec2에서 새로운 인스턴스를 만들어서 ssh 비밀번호로 접속하는 것만 다시 해봤다. 새로운 유저를 만들어서 권한을 주었더니 바로 성공했다. 다음은 인스턴스를 만들고 난 직후부터 성공하기까지 인스터스 서버에서 했던 작업이다. 

# 업데이트
sudo apt-get update
sudo apt-get upgrade
sudo apt update
sudo apt upgrade

# 유저 생성
sudo adduser rimi

# 권한 변경
sudo vi /etc/sudoers
# root ALL=(ALL:ALL) ALL 바로 밑 줄에
# rimi ALL=(ALL:ALL) 삽입

sudo vi /etc/passwd
# 본인 계정명의 숫자를 root의 숫자와 동일하게 변경

sudo vi /etc/group
# 맨 윗줄 root:x:0옆에 rimi 추가

# ssh 옵션 변경
sudo vi /etc/ssh/sshd_config
# PermitRootLogin yes
# PasswordAuthentication yes
# PubkeyAuthentication yes

# ssh 다시 시작
sudo service sshd restart

 

참고 : https://taepseon.tistory.com/190

리눅스 사용자 권한 주는 법

 

 rimi 계정으로 성공한 후 ubuntu, root로 시도했는데 둘 다 잘됐다. 계정 권한의 문제가 아니라 sshd_config 옵션 설정이 잘못된 것 같다고 판단했다. 그래서 새로운 인스턴스(성공)의 /etc/ssh/sshd_config 파일과 기존 인스턴스(실패)의 /etc/ssh/sshd_config 파일을 비교했다. 그랬더니 다음의 부분만 옵션이 다르게 주어져있는 것을 발견했다.

 

기존 인스턴스 (잘 안되는 인스턴스) : KbdInteractiveAuthentication no

신규 인스턴스 (성공한 인스턴스) : ChallengeResponseAuthentication no

 

" KbdInteractiveAuthentication no " 이 옵션을 구글링해보니 키보드를 통해 비밀번호로 접근하는걸 막는 옵션이었다.. 

---

 "KbdInteractiveAuthentication no"는 SSH 구성 옵션 중 하나로, SSH 클라이언트가 키보드 대화형 인증 방법을 사용하지 않도록 설정하는 것입니다. 일반적으로 SSH 세션에서 사용자에게 비밀번호 또는 다른 인증 요청이 표시되지 않도록 하기 위해 설정됩니다. SSH는 여러 가지 인증 방법을 지원합니다. 그 중 하나는 키보드 대화형 인증입니다. 이 방법은 SSH 서버가 사용자에게 비밀번호나 기타 인증 정보를 요청하고, 사용자가 키보드를 사용하여 해당 정보를 입력하는 것입니다.

 그러나 보안을 높이기 위해 이러한 대화형 인증이 비활성화되는 경우가 있습니다. "KbdInteractiveAuthentication no"를 설정하면 SSH 클라이언트가 대화형 인증 방법을 사용하지 않도록 강제됩니다. 대신, 클라이언트는 공개 키 기반 인증 또는 기타 비대화형 방법을 사용하여 인증해야 합니다. 이 옵션은 일반적으로 보안 설정의 일부로 사용되며, 특히 자동화된 SSH 연결이나 스크립트에서 사용될 때 키보드 입력에 의존하지 않도록 하기 위해 설정됩니다.

---

하... 이런 옵션이 껴있었다니!!!!!!!!!!!!!!!!!!!!!!

이 옵션을 주석처리 하니까 드디어 ssh 비밀번호 연결에 성공했다. 

해결 : KbdInteractiveAuthentication no 옵션 주석처리하기

---

/etc/ssh/sshd_config