SSH 키 인증

Обновлено 1 месяц назад

비밀번호는 누군가 보고 있지 않기를 바라며 상자에 입력하는 비밀입니다. SSH 키는 컴퓨터를 절대 떠나지 않는 비밀이지만, 그럼에도 당신이 누구인지 증명해냅니다.

이것은 사소한 개선이 아닙니다. 근본적으로 다른 인증 방식입니다.

핵심 원리

공개 키 암호화는 불가능해 보이는 문제를 해결합니다: 비밀을 드러내지 않고 어떻게 그 비밀을 가지고 있다는 것을 증명할 수 있을까요?

답은 수학적 단방향 함수에 있지만, 실제 결과는 간단합니다. 수학적으로 연결된 두 개의 키—개인 키와 공개 키—를 생성합니다. 하나로 암호화된 데이터는 다른 하나로만 복호화할 수 있습니다.

개인 키는 컴퓨터에 보관됩니다. 어디에도 전송하지 않습니다. 절대 공유하지 않습니다. 누군가 이것을 얻으면 당신을 사칭할 수 있습니다.

공개 키는 어디에나 배포해도 됩니다. 웹사이트에 올리거나, 낯선 사람에게 이메일로 보내거나, 접근하는 모든 서버에 설치해도 됩니다. 누가 가지고 있어도 상관없습니다. 공개 키는 개인 키를 소유하고 있다는 것을 확인하는 데만 쓸 수 있을 뿐, 개인 키를 역으로 추출하거나 사칭하는 데는 사용할 수 없습니다.

이 비대칭성이 바로 이 방식의 핵심입니다.

인증 과정

SSH 키 인증으로 서버에 연결할 때 실제로 일어나는 일은 다음과 같습니다:

서버에 공개 키가 등록되어 있습니다
서버가 임의의 도전값을 생성하고 공개 키로 암호화합니다
컴퓨터가 이 암호화된 데이터를 수신합니다
컴퓨터가 개인 키로 복호화합니다
컴퓨터가 복호화 성공 증명을 전송합니다
서버가 증명을 확인하고 접속을 허용합니다

개인 키는 네트워크를 통해 전달되지 않습니다. 연결을 감시하는 공격자는 암호화된 도전값과 응답만 볼 수 있을 뿐, 이를 이용해 사칭하거나 재사용할 수 없습니다.

비밀번호를 사용하면 비밀 자체를 전송합니다. 키를 사용하면 비밀을 드러내지 않고도 그것을 가지고 있다는 것을 증명합니다.

키 생성

ssh-keygen 명령어로 키 쌍을 만들 수 있습니다:

ssh-keygen -t ed25519 -C "your_email@example.com"

ED25519 키가 현대적인 표준입니다. RSA보다 짧고, 빠르며, 더 안전합니다. -C 플래그는 나중에 키를 식별하기 위한 주석(이메일)을 추가합니다.

패스프레이즈를 물어봅니다. 디스크에 저장된 개인 키를 암호화합니다. 누군가 키 파일을 훔쳐도 패스프레이즈 없이는 사용할 수 없습니다. 키를 사용할 때마다 패스프레이즈를 입력해야 하지만, SSH 에이전트가 이를 기억해줄 수 있습니다.

이 과정에서 두 파일이 생성됩니다:

~/.ssh/id_ed25519 — 개인 키 (잘 보관하세요)
~/.ssh/id_ed25519.pub — 공개 키 (자유롭게 공유해도 됩니다)

ED25519를 지원하지 않는 구형 시스템이라면 4096비트 RSA를 사용하세요:

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

공개 키 설치

키 인증이 작동하려면 서버에 공개 키가 있어야 합니다. 가장 쉬운 방법:

ssh-copy-id username@server

비밀번호로 마지막 한 번 접속해서 공개 키를 서버의 ~/.ssh/authorized_keys 파일에 복사하고 올바른 권한을 설정합니다. 이후에는 키로 인증할 수 있습니다.

ssh-copy-id를 사용할 수 없다면 수동으로 키를 복사합니다. 공개 키 내용을 확인하려면:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519로 시작하는 한 줄이 표시됩니다. 이를 복사하고 비밀번호로 서버에 접속한 다음, 다음과 같이 추가합니다:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "ssh-ed25519 AAAA...your-key-here..." >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

권한 설정이 중요합니다. SSH는 다른 사용자가 읽을 수 있는 authorized_keys 파일을 사용하지 않습니다.

여러 키 관리

업무, 개인 프로젝트, 자동화 시스템마다 별도의 키를 사용할 수 있습니다. 이름을 다르게 지정해 생성하세요:

ssh-keygen -t ed25519 -f ~/.ssh/id_work
ssh-keygen -t ed25519 -f ~/.ssh/id_personal

-i 옵션으로 사용할 키를 지정할 수 있습니다:

ssh -i ~/.ssh/id_work username@work-server

하지만 매번 입력하는 것은 번거롭습니다. SSH 설정 파일(~/.ssh/config)을 활용하는 것이 훨씬 편합니다:

Host work
    HostName 192.168.1.10
    User admin
    IdentityFile ~/.ssh/id_work

Host personal
    HostName example.com
    User me
    IdentityFile ~/.ssh/id_personal

이제 ssh work와 ssh personal을 입력하면 올바른 키, 호스트명, 사용자명이 자동으로 적용됩니다.

SSH 에이전트

매번 패스프레이즈를 입력해야 한다면 키의 편의성이 반감됩니다. SSH 에이전트가 이 문제를 해결합니다.

에이전트는 백그라운드에서 실행되며, 복호화된 개인 키를 메모리에 보관합니다. SSH가 인증이 필요할 때 에이전트에 요청합니다. 세션 동안 패스프레이즈는 한 번만 입력하면 됩니다.

에이전트에 키를 추가합니다:

ssh-add ~/.ssh/id_ed25519

macOS에서는 시스템 키체인을 사용하도록 SSH를 설정할 수 있습니다:

Host *
    AddKeysToAgent yes
    UseKeychain yes

서버를 경유하는 연결

때로는 중간 서버를 거쳐 연결해야 할 때가 있습니다. 에이전트 포워딩을 사용하면 로컬 키로 이후 서버에서도 인증할 수 있습니다:

ssh -A username@jump-server

점프 서버에서 로컬 키를 사용해 다른 서버로 SSH 접속할 수 있습니다.

하지만 위험이 따릅니다. 점프 서버에 루트 권한을 가진 사람은 연결된 동안 포워딩된 에이전트를 가로챌 수 있습니다. 더 안전한 대안은 ProxyJump입니다:

ssh -J jump-server final-server

이것은 에이전트를 노출하지 않고 점프 서버를 통한 직접적인 암호화 터널을 생성합니다.

접근 권한 취소

여기서 키가 비밀번호보다 훨씬 뛰어납니다.

접근을 취소하려면 서버의 ~/.ssh/authorized_keys에서 해당 공개 키를 제거하면 됩니다. 그것으로 끝입니다. 그 개인 키는 어디에 있든 더 이상 인증할 수 없습니다.

각 키는 고유합니다. 사람이나 시스템마다 다른 키를 부여할 수 있습니다. 누군가 떠나거나 키가 노출되면 해당 키만 제거합니다. 다른 접근에는 영향이 없습니다.

비밀번호라면 취소를 위해 공유 비밀을 변경하고 새로운 것을 배포해야 합니다. 키는 외과적으로 정밀하게 처리할 수 있습니다.

보안 모범 사례

패스프레이즈를 사용하세요. 도난된 키 파일도 패스프레이즈 없이는 쓸모가 없습니다.

권한을 제한하세요:

chmod 600 ~/.ssh/id_ed25519
chmod 700 ~/.ssh

SSH는 권한이 느슨한 키를 거부합니다.

서버에 개인 키를 복사하지 마세요. 대신 에이전트 포워딩이나 ProxyJump를 사용하세요.

주기적으로 키를 교체하세요. 1~2년마다 새로운 키를 생성하세요.

키가 잘 작동하면 비밀번호 인증을 비활성화하세요. /etc/ssh/sshd_config를 편집합니다:

PasswordAuthentication no

이렇게 하면 비밀번호 기반 공격이 완전히 차단됩니다.

자동화를 위한 키

스크립트와 배포 시스템은 패스프레이즈를 입력할 수 없습니다. 자동화를 위해서는 패스프레이즈 없는 전용 키를 생성하되, 비밀처럼 다루세요. 접근을 제한하고, 목적을 문서화하고, 필요한 곳에만 설치하세요.

구성 관리 도구(Ansible, Puppet, Chef), CI/CD 시스템, 모니터링 도구 모두 SSH 키에 의존합니다. 대안인 스크립트에 비밀번호를 직접 넣는 방식은 훨씬 더 위험합니다.

대규모 환경으로 확장

대규모 조직은 추가 도구를 활용합니다:

구성 관리는 모든 서버에 공개 키를 자동으로 배포합니다.

배스천 호스트는 접근을 중앙화합니다. 모든 연결이 하나의 강화된 서버를 통과합니다.

SSH 인증서는 인증 기관이 만료일이 있는 키에 서명할 수 있게 하여, 각 서버의 개별 키를 관리하지 않고도 중앙에서 제어할 수 있게 합니다.

디렉터리 통합은 SSH 접근을 LDAP 또는 Active Directory 그룹에 연결합니다.

하지만 원칙은 동일합니다: 개인 키 소유가 신원을 증명하고, 공개 키 제거가 접근을 취소합니다.

SSH 키 인증에 관한 자주 묻는 질문

개인 키를 잃어버리면 어떻게 되나요?

해당 키만 인증된 모든 서버에 대한 접근을 잃게 됩니다. 새로운 키 쌍을 생성하고 새 공개 키를 설치하세요. 이것이 일부 사람들이 개인 키의 암호화된 백업을 보관하고, 조직이 여러 인증 키나 중앙 인증 시스템을 사용하는 이유입니다.

여러 컴퓨터에서 같은 키 쌍을 사용할 수 있나요?

기술적으로는 가능합니다. 개인 키를 다른 기기에 복사할 수 있습니다. 하지만 각 컴퓨터에서 고유한 키 쌍을 생성하는 것이 더 안전합니다. 한 기기가 노출되면 해당 키만 취소하면 됩니다.

SSH가 "Permission denied"로 키를 거부하는 이유는 무엇인가요?

대부분 권한 문제입니다. ~/.ssh가 700 모드가 아니거나 authorized_keys가 600 모드가 아니면 서버가 키를 거부합니다. 다른 원인으로는 공개 키가 authorized_keys에 없거나, 잘못된 사용자명을 사용하거나, 서버에서 키 인증이 비활성화된 경우가 있습니다.

SSH 에이전트를 사용하더라도 패스프레이즈가 필요한가요?

네. 패스프레이즈는 저장된 키 파일을 보호합니다. 패스프레이즈가 없으면 키 파일을 손에 넣은 사람은 누구든 당신을 사칭할 수 있습니다. 에이전트는 패스프레이즈를 반복해서 입력하지 않아도 되게 해줄 뿐, 보안 수준을 낮추지는 않습니다.

HTTPS 인증서와 어떻게 다른가요?

같은 암호화 기반을 사용하지만 용도가 다릅니다. HTTPS 인증서는 클라이언트에게 서버의 신원을 증명합니다. SSH 키는 서버에게 클라이언트의 신원을 증명합니다. 둘 다 공개 키 암호화를 사용하지만, SSH 키는 일반적으로 직접 생성하는 반면 HTTPS 인증서는 인증 기관이 서명합니다.

SSH란 무엇인가?

VNC (가상 네트워크 컴퓨팅)

Была ли эта страница полезной?

😔

🤨

😃