SSH 키 인증 입문: 공개키, 개인키, ssh config의 구조 완벽 이해

이전 장에서 SSH를 통한 최초 로그인을 진행했습니다. 비밀번호 로그인은 직관적이지만 취약한 암호, 재사용, 무차별 대입 공격에 취약합니다. 표준적인 운영 방식은 SSH 공개키 인증을 사용하는 것입니다.

"공개키, 개인키, 호스트 키"라는 용어는 초보자를 혼란스럽게 만듭니다. 핵심 원칙을 먼저 기억하세요: 사용자 키는 '내가 누구인지'를 증명하고, 호스트 키는 '상대 서버가 진짜인지'를 증명합니다.

1. 공개키와 개인키의 협업 원리

물리적인 자물쇠와 열쇠에 비유할 수 있습니다:

서버는 공개키만 보관하며, 개인키를 건네받을 필요가 없습니다. 로그인 시 암호학적 챌린지-응답 과정을 통해 검증이 이루어지며, 개인키 자체가 네트워크를 타고 전송되지 않습니다.

따라서 튜토리얼에서 "개인키를 서버에 업로드하라"고 요구한다면 즉시 의심해야 합니다. 개인키를 공개 Git 저장소, 블로그 캡처 화면, 메신저 대화방, 클라우드 링크로 공유해서는 안 됩니다.

2. 학습용 VPS 전용 키페어 생성하기

Mac이나 Linux 로컬 터미널에서 독립적인 Ed25519 키페어를 생성합니다:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_vps_learning -C "vps-learning"

명령어 옵션 설명:

• -t ed25519: 현대적이고 보안성이 뛰어난 Ed25519 서명 알고리즘 선택;
• -f: 기존 키를 실수로 덮어쓰지 않도록 고유 파일명 명시;
• -C: 식별용 주석 추가 (인증에는 영향을 주지 않음).

암호 구문(패스프레이즈) 설정 프롬프트가 나타나면 강력한 암호를 지정하세요. 일상 작업 시 OS 키체인이나 ssh-agent를 활용하면 매번 암호를 입력하는 번거로움을 줄일 수 있습니다.

생성되는 두 파일:

~/.ssh/id_ed25519_vps_learning       개인키 (절대 유출 금지)
~/.ssh/id_ed25519_vps_learning.pub   공개키 (서버에 등록할 대상)

3. 서버에 공개키 등록하기

가장 확실한 방법은 VPS 호스팅 업체의 관리 패널에서 제공하는 SSH Key 기능을 이용해 인스턴스 생성 시 .pub 파일의 내용을 붙여넣는 것입니다. 이미 비밀번호 로그인이 가능한 상태라면 ssh-copy-id 명령어를 사용할 수도 있습니다.

어떤 방식을 쓰든, 서버 내부에서는 대상 사용자의 다음 파일에 공개키가 한 줄로 추가됩니다:

~/.ssh/authorized_keys

SSH는 파일 권한을 엄격하게 검사합니다. 일반적으로 ~/.ssh 디렉터리는 소유자만 접근 가능(700), authorized_keys 파일은 소유자만 쓰기 가능(600)이어야 합니다. 권한이 과도하게 열려 있으면 SSH 데몬이 보안을 위해 키 인증을 거부합니다.

확인해야 할 3가지 사항:

1. 올바른 Linux 사용자의 홈 디렉터리에 설치되었는가; 2. 붙여넣은 내용이 개인키가 아닌 .pub 공개키 내용인가; 3. 비밀번호 로그인을 비활성화하기 전에 별도 창에서 키 로그인이 되는지 확인했는가.

4. SSH config로 긴 명령어를 간소화하기

매번 ssh -i ~/.ssh/id_ed25519_vps_learning admin@203.0.113.10을 입력하는 것은 비효율적입니다.

로컬 컴퓨터의 ~/.ssh/config 파일에 별칭을 추가하세요:

Host learning-vps
  HostName 203.0.113.10
  User admin
  Port 22
  IdentityFile ~/.ssh/id_ed25519_vps_learning
  IdentitiesOnly yes

이제 다음 한 줄로 접속할 수 있습니다:

ssh learning-vps

Host는 로컬에서 사용할 단축 별칭이며, HostName이 실제 서버 IP입니다. IdentitiesOnly yes는 지정된 키만 시도하도록 강제하여 로컬에 키가 많을 때 발생하는 인증 실패를 방지합니다.

5. 사용자 키와 호스트 키를 혼동하지 말 것

최초 접속 시 확인한 SHA256 해시는 호스트 키의 핑거프린트입니다. 향후 호스트 키가 갑자기 변경된다면 OS 재설치 때문인지, IP 재할당이나 네트워크 가로채기 때문인지 확인하세요.

6. 안전한 인증 방식 전환 순서

비밀번호 로그인에서 키 인증으로 전환할 때는 다음 순서를 따릅니다:

1. 웹 콘솔 비상 구난 수단을 확인한다; 2. 일반 관리용 사용자를 생성하고 공개키를 등록한다; 3. 기존 SSH 세션을 닫지 않은 상태에서, 새 터미널을 열어 키 로그인을 검증한다; 4. 새 사용자에게 필요한 sudo 권한이 올바르게 동작하는지 확인한다; 5. sshd_config에서 root 직접 로그인 및 비밀번호 인증 비활성화를 단계적으로 적용한다; 6. 수정할 때마다 새 세션을 열어 확인하고 인증 로그를 점검한다.

포트, 방화벽, 사용자 계정, 인증 방식을 한 번에 바꾸지 않는 것이 철칙입니다.

7. SSH 키의 라이프사이클 관리

• 기기나 용도별로 식별 가능한 독립 키페어를 사용한다;
• 기기를 폐기하거나 팀원이 퇴사할 때 authorized_keys에서 해당 공개키를 즉시 삭제한다;
• 개인키 유출이 의심되면 즉시 새 키페어를 생성·배포하고 구 공개키를 폐기한다;
• 개인키 백업은 신뢰할 수 있는 방식으로 암호화하고 복원 테스트를 거친다;
• "키에 만료일이 없다"고 해서 "영원히 교체하지 않아도 된다"고 착각하지 않는다.

8. 요약

SSH 키 인증은 단순히 더 긴 비밀번호가 아닙니다. 공개 가능한 자물쇠(공개키)와 로컬에만 보관하는 열쇠(개인키)를 수학적으로 분리하는 체계입니다. ~/.ssh/config를 함께 활용하면 안전하고 효율적인 서버 관리가 가능해집니다.

자주 묻는 질문 (FAQ)

.pub 파일은 남에게 보내도 안전한가요?

공개키는 배포를 목적으로 만들어진 파일이지만, 접근 권한을 부여할 신뢰할 수 있는 서버에만 등록해야 합니다. 개인키 파일은 절대로 타인에게 전달해서는 안 됩니다.

비밀번호가 걸린 개인키로 자동화 배치를 돌리려면 어떻게 하나요?

권한이 제한된 전용 키, ssh-agent, 단기 자격 증명, 시크릿 관리 도구를 활용하세요. 편의를 위해 암호 없는 특권 개인키를 무분별하게 복제하는 것은 피해야 합니다.

비밀번호 로그인은 완전히 차단해야 하나요?

키 인증, sudo 권한, 웹 콘솔 동작 검증이 끝난 후 비활성화하는 것을 권장합니다. 동작이 확인되지 않은 상태에서 덮어놓고 끄지 마세요.

참고 자료

• OpenBSD Manual Pages: ssh-keygen
• OpenBSD Manual Pages: ssh_config
• OpenBSD Manual Pages: sshd_config
• Ubuntu Server: OpenSSH Server
• RFC Editor: RFC 5737 문서용 예약 IPv4 주소