우분투 SSH 키 기반 인증 설정과 원격 접속 문제 해결 방법

우분투 SSH 키 기반 인증의 필요성과 학습 목표

우분투 서버를 외부에 노출하거나 클라우드 환경에서 운영할 때, 기본 비밀번호 로그인 방식은 무차별 대입 공격(Brute Force Attack)에 취약합니다. 비밀번호를 복잡하게 설정하더라도 로그 유출 위험이 항상 존재하기 때문에, 암호학적 비대칭 키를 이용한 SSH 키 기반 인증 설정은 실무 서버 운영의 필수 기초 작업입니다.

이 글에서는 로컬 PC에서 공개키와 개인키를 생성하고, 우분투 서버에 안전하게 등록한 뒤 비밀번호 로그인을 차단하는 절차를 살펴봅니다. 또한 접속 과정에서 흔히 발생하는 권한 오류나 설정 실수로 인해 로그인이 차단되었을 때 진단하고 대처하는 실무 요령을 함께 다룹니다.

사전 준비 사항 및 주의점

작업을 시작하기 전에 다음 사항을 반드시 확인해야 합니다.

루트 권한 확보: 설정 파일을 수정하고 서비스를 재시작하기 위해 sudo 권한을 가진 일반 사용자 계정이 필요합니다.
세션 유지 주의: SSH 설정을 변경하는 도중에는 현재 연결된 터미널 창을 닫거나 종료하지 마십시오. 설정 오류가 발생했을 때 기존 세션을 유지한 채 다른 터미널에서 새 설정으로 접속 테스트를 진행해야 서버 잠김(Lockout) 사고를 예방할 수 있습니다.

1단계: 로컬 PC에서 SSH 키 쌍 생성하기

공개키(Public Key)와 개인키(Private Key)를 생성하려면 로컬 관리자 PC(윈도우 터미널, 맥, 리눅스)의 터미널을 열고 다음 명령어를 실행합니다.

ssh-keygen -t rsa -b 4096

명령어를 실행하면 저장 경로를 묻는 메시지가 나오며, 기본값(Enter)을 사용하는 것이 무난합니다. 이후 키를 보호하기 위한 비밀번호(Passphrase) 입력 단계가 나타나는데, 필요에 따라 입력하거나 엔터를 눌러 빈 값으로 둘 수 있습니다.

생성된 키는 일반적으로 사용자 홈 디렉터리의 ~/.ssh/ 폴더 안에 id_rsa(개인키)와 id_rsa.pub(공개키) 파일로 저장됩니다.

2단계: 공개키를 우분투 서버로 복사하기

생성된 공개키를 원격 우분투 서버의 특정 사용자 계정으로 전송하여 인증 목록에 추가해야 합니다. 가장 안전하고 간편한 도구는 ssh-copy-id입니다.

ssh-copy-id 사용자이름@서버_IP_주소

명령어를 실행하면 대상 계정의 현재 비밀번호를 한 차례 묻습니다. 인증이 완료되면 공개키가 서버의 ~/.ssh/authorized_keys 파일에 자동으로 추가됩니다. 이 명령어가 작동하지 않는 환경이라면, 서버에 직접 로그인하여 ~/.ssh 디렉터리를 만들고 authorized_keys 파일에 공개키 내용을 직접 붙여넣을 수도 있습니다.

3단계: SSH 데몬 설정 변경 및 비밀번호 로그인 차단

키 등록이 끝났다면 서버의 SSH 설정 파일을 수정하여 보안성을 높입니다. 설정 파일을 열기 전에 원본을 백업하는 것이 안전합니다.

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

이어서 편집기로 설정 파일을 엽니다.

sudo nano /etc/ssh/sshd_config

파일 내부에서 다음 항목들을 찾아 주석(#)을 해제하거나 값을 수정합니다.

PubkeyAuthentication yes (공개키 인증 활성화)
PasswordAuthentication no (비밀번호 로그인 차단, 키 설정이 완벽히 끝난 후 적용)
PermitRootLogin no (루트 계정의 직접 원격 로그인 차단)

파일을 저장하고 나온 뒤, 설정에 문법 오류가 없는지 검증합니다.

sudo sshd -t

오류 메시지가 출력되지 않는다면 서비스를 재시작하여 변경 사항을 적용합니다.

sudo systemctl restart ssh (또는 sshd)

4단계: 접속 문제 진단 및 로그 점검 요령

설정 변경 후 로그인이 거부되거나 연결이 끊기는 문제가 발생하면, 원인을 빠르게 파악해야 합니다. 클라이언트에서 디버그 모드로 접속을 시도하면 상세한 원인을 볼 수 있습니다.

ssh -v 사용자이름@서버_IP_주소

서버 측에서는 systemd 저널 로그를 통해 SSH 인증 실패 원인을 확인할 수 있습니다.

sudo journalctl -u ssh -e

흔히 발생하는 실수

권한 설정 오류: 서버의 ~/.ssh 디렉터리 권한이 700, authorized_keys 파일 권한이 600이 아니면 보안상 이유로 SSH 서버가 키 인증을 무시합니다. chmod 700 ~/.ssh와 chmod 600 ~/.ssh/authorized_keys 명령어로 권한을 바로잡아야 합니다.
테스트 전 세션 종료: 비밀번호 로그인을 차단(PasswordAuthentication no)한 상태에서 키 인증이 제대로 작동하는지 확인하지 않고 터미널을 닫아버리면 서버 접근이 완전히 차단됩니다. 반드시 새 터미널 창을 띄워 접속 테스트를 마친 후 기존 세션을 닫으세요.
공개키 파일명 오타: 수동으로 키를 복사할 때 authorized_keys 파일의 철자나 줄바꿈에 오류가 생기면 로그인이 실패합니다.

실무 적용 체크리스트

로컬 PC에서 ssh-keygen 명령어로 키 쌍을 생성했는가?
ssh-copy-id 또는 수동 방식을 통해 authorized_keys에 공개키가 정확히 등록되었는가?
서버의 ~/.ssh(700)와 authorized_keys(600) 파일 권한이 올바르게 설정되었는가?
비밀번호 로그인을 차단하기 전, 새 터미널 창에서 키 기반 로그인이 정상 작동하는지 확인했는가?
sudo sshd -t 명령어로 설정 파일 문법 검증을 마쳤는가?