SSH key 관리 방법 및 ed25519 키 생성 가이드

SSH key의 작동 원리

SSH key는 한 쌍의 파일로 구성됩니다. 기기에 보관하는 private key와 접속하려는 모든 서버에 복사해 두는 public key가 그것입니다. 연결 시 서버는 public key를 사용하여 challenge를 보냅니다. 이 challenge는 일치하는 private key로만 응답할 수 있습니다. private key는 기기를 벗어나지 않으므로 네트워크를 통해 비밀 정보가 전송되지 않습니다. 따라서 서버가 침해당하더라도 탈취할 유용한 정보가 없습니다. 이것이 key가 password보다 우수한 이유입니다. SSH key를 잘 관리하려면 네 가지 습관이 필요합니다. 기기당 하나의 key 사용, sshd가 요구하는 파일 권한 준수, 옵션 입력을 줄여주는 ~/.ssh/config 파일 사용, 그리고 노트북 분실 시 즉시 key를 삭제하는 방법 숙지입니다.

이 가이드는 Ubuntu 24.04를 기준으로 각 습관을 설명합니다. 하지만 대부분의 내용은 모든 Linux server 및 최신 OpenSSH에 적용됩니다.

실수를 방지하기 위해 용어 정의를 먼저 확인합니다. public key는 비밀이 아닙니다. 티켓에 붙여넣거나 이메일로 전송하거나 공개해도 아무도 이 키로 로그인할 수 없습니다. private key가 비밀입니다. 누군가 이 파일을 복사하고 passphrase를 알고 있다면, 서버 입장에서는 그 사람이 바로 사용자 본인입니다.

키 생성: ed25519가 적절한 기본값입니다

서버가 아닌 본인의 컴퓨터에서 다음 명령어를 실행하십시오:

ssh-keygen -t ed25519 -C "laptop"

-t ed25519은 키 유형을 선택합니다. Ed25519는 현대적인 기본값입니다. 이 키는 길이가 짧고 빠르며, 2014년 이후 모든 OpenSSH 버전에서 지원됩니다. ed25519를 지원하지 않는 오래된 장치와 통신해야 하는 경우에만 ssh-keygen -t rsa -b 4096를 사용하십시오. -C "laptop"은 주석을 설정합니다. 주석은 암호학적 기능을 수행하지 않습니다. 하지만 2년 후 서버의 authorized_keys 파일에서 이 키를 식별하는 용도로 사용됩니다. 따라서 키가 저장된 장치의 이름을 입력하십시오.

ssh-keygen은 키 저장 위치를 묻습니다. 기본값인 ~/.ssh/id_ed25519을 사용하십시오. 그 다음 암호를 묻습니다. 암호를 설정하십시오. 아래의 암호 섹션에서 일상적인 사용에 지장이 없는 이유를 설명합니다. 작업이 완료되면 두 개의 파일이 생성됩니다. ~/.ssh/id_ed25519은 개인 키(private key)이며, ~/.ssh/id_ed25519.pub은 공개 키(public key)입니다. 공개 키의 내용을 확인하십시오:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

내용은 한 줄로 구성됩니다. 키 유형, 키 데이터, 그리고 주석이 포함됩니다. 이 한 줄이 서버에 저장되는 내용입니다.

서버당 하나가 아닌, 디바이스당 하나의 키 사용

가장 먼저 나오는 질문은 다음과 같습니다. 모든 서버마다 새로운 키가 필요한가요? 아닙니다. 사용 중인 디바이스마다 키를 하나씩 생성하십시오. 그리고 해당 디바이스가 접속해야 하는 모든 서버에 그 공개 키를 등록하십시오. 키는 디바이스를 식별합니다. 각 서버의 authorized_keys 파일은 접속이 허용된 디바이스 목록입니다.

이 방식은 확장이 용이하며, 다른 방식들은 예측 가능한 문제점을 가집니다. 서버마다 키를 생성하는 방식은 노트북 한 대에 20개의 서버가 연결될 경우 20개의 private key를 보관해야 함을 의미하며, 이로 인해 키를 식별하기 어려워집니다. 모든 디바이스가 하나의 키를 공유하는 방식은 더 위험합니다. 노트북을 분실했을 때, 모든 디바이스가 동일한 private key를 사용하므로 노트북만 개별적으로 무효화할 수 없습니다. 이 경우 모든 디바이스에 키를 다시 배포해야 합니다.

디바이스당 하나의 키를 사용하면, 노트북 분실 시 서버당 한 줄의 수정만 필요합니다. authorized_keys 파일에서 해당 노트북의 라인을 삭제하면 다른 디바이스들은 계속 작동합니다. -C으로 설정한 comment를 통해 해당 라인을 쉽게 찾을 수 있습니다.

이 모델의 원칙은 다음과 같습니다. private key는 디바이스에서 생성되며 해당 디바이스와 함께 소멸합니다. private key를 다른 기기로 복사하거나 서버에 업로드하지 마십시오. 새로운 디바이스에 권한이 필요한 경우, 해당 디바이스에서 새로운 키를 생성하십시오.

서버에 public key 저장하기

가장 쉬운 방법은 OpenSSH에 포함된 ssh-copy-id를 사용하는 것입니다:

ssh-copy-id matt@10.0.0.10

이 도구는 기존의 방식(보통 password)으로 로그인한 뒤, 서버의 ~/.ssh/authorized_keys에 public key를 추가합니다. 디렉토리와 파일이 없다면 올바른 권한과 함께 새로 생성합니다. 새로운 SSH 세션을 열어 테스트하십시오. 서버가 계정 password를 묻지 않고 접속되어야 합니다. 만약 key에 passphrase가 설정되어 있다면, 로컬 머신에서 이를 요청할 수 있습니다. 이 요청은 로컬 작업이며 서버 password와는 무관합니다.

이미 password login이 비활성화된 상태라면 ssh-copy-id을 사용할 수 없으므로, 직접 line을 추가해야 합니다. 여전히 접속 가능한 세션이나 제공업체의 web console을 통해 로그인한 후, 서버에서 다음 명령어를 실행하십시오:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

따옴표 안에 id_ed25519.pub에서 복사한 전체 single line을 붙여넣으십시오. authorized_keys은 한 line당 하나의 public key를 저장하며, 이것이 전체 access database입니다. 장치를 추가하려면 line을 추가하고, 장치 권한을 취소하려면 해당 line을 삭제하십시오. 신규 서버의 경우, 이 단계는 password login을 비활성화하기 직전인 신규 VPS 초기 설정 10분 이내 과정에 포함됩니다.

키 로그인을 방해하는 권한 설정

이것은 키 로그인이 실패하는 가장 흔한 원인이며, 클라이언트 측에서는 오류 메시지 없이 조용히 실패합니다. Ubuntu 24.04에서 sshd는 기본적으로 StrictModes yes로 실행됩니다. 이는 다른 사용자가 수정할 수 있는 authorized_keys 파일을 사용하는 것을 거부함을 의미합니다. 파일, ~/.ssh 디렉터리 또는 홈 디렉터리가 사용자 본인 외의 다른 사용자에 의해 쓰기 권한이 허용되어 있다면, sshd는 키를 무시하고 비밀번호 입력을 요청합니다. 이때 클라이언트에는 아무런 설명이 나타나지 않습니다. (Ubuntu의 OpenSSH는 단 한 가지 예외를 허용합니다. 본인이 속한 프라이빗 그룹만 쓰기 권한을 가진 파일 그룹입니다. 이 예외에 의존하지 마십시오. 아래의 권한 설정을 유지하십시오.) 원인은 서버 로그에만 나타납니다:

sudo grep 'Authentication refused' /var/log/auth.log

rsyslog가 없는 최소 설치 이미지에는 auth.log가 없습니다. 동일한 로그 라인이 journal에 기록됩니다: sudo journalctl -u ssh | grep 'Authentication refused'.

Authentication refused: bad ownership or modes for file /home/matt/.ssh/authorized_keys

해결 방법은 서버에서 해당 사용자로 두 가지 권한 변경과 소유권 확인을 실행하는 것입니다:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R matt:matt ~/.ssh

기억해야 할 규칙: .ssh 디렉터리에는 700를, 그 내부의 모든 항목에는 600를 적용하십시오. 클라이언트도 검사를 수행하므로 동일한 숫자를 본인의 컴퓨터에도 적용해야 합니다. 다른 사용자가 읽을 수 있는 프라이빗 키는 ssh이 키 사용을 즉시 거부하게 만들며, 이번에는 오류가 명확하게 표시됩니다:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/matt/.ssh/id_ed25519' are too open.

chmod 600 ~/.ssh/id_ed25519으로 해결할 수 있습니다.

~/.ssh/config: 옵션 입력 생략하기

로컬 컴퓨터의 ~/.ssh/config 파일은 각 서버에 짧은 이름을 부여하고 반복되는 옵션을 저장합니다. 600 권한으로 파일을 생성하고 서버당 하나의 Host 블록을 추가하십시오.

Host web1
    HostName 10.0.0.10
    User matt
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host db1
    HostName 10.0.0.11
    User matt
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

이제 ssh web1가 ssh -p 22 matt@10.0.0.10을(를) 대체합니다. 모든 서버가 이 파일을 읽으므로 동일한 짧은 이름이 scp, rsync, git에서 모두 작동합니다. HostName은(는) 실제 주소이며, User은(는) 계정 이름 입력을 생략하게 해주고, IdentityFile은(는) 사용할 키를 지정합니다.

IdentitiesOnly yes은(는) 혼란스러운 오류를 해결하므로 설명이 필요합니다. SSH agent에 여러 키가 로드되어 있으면, 클라이언트는 키를 하나씩 제시하며 서버는 각 제시를 실패한 시도로 간주합니다. 키가 충분히 로드되어 있으면 올바른 키를 시도하기 전에 Received disconnect: Too many authentication failures이(가) 발생합니다. IdentitiesOnly yes을(를) 사용하면 클라이언트가 IdentityFile에 지정된 키만 제시하므로 이러한 오류가 발생하지 않습니다.

Passphrases and ssh-agent

Passphrase는 디스크에 저장된 private key 파일을 암호화합니다. Passphrase가 없으면 파일을 복사한 누구나 즉시 해당 키를 사용할 수 있습니다. Passphrase를 설정하면 암호를 알아내기 전까지는 유출된 파일이 무용지물이 됩니다. 노트북은 분실 위험이 있고 백업 데이터가 유출될 수 있으므로, 노트북용 키에는 이러한 보호 조치가 반드시 필요합니다.

실제로 Passphrase를 사용하는 데 비용이 들지 않는 이유는 ssh-agent 때문입니다. agent가 복호화된 키를 메모리에 보관하므로, 로그인 세션당 한 번만 암호를 입력하면 이후 모든 연결이 즉시 이루어집니다. 대부분의 desktop Linux 배포판과 macOS에는 이미 agent가 실행 중입니다. 다음 명령어로 키를 agent에 로드하십시오:

ssh-add ~/.ssh/id_ed25519

ssh-add -l 명령어를 사용하면 agent가 현재 보유 중인 키 목록을 확인할 수 있습니다. 주의할 점이 있습니다. agent forwarding (ssh -A)을 사용하면 연결된 동안 원격 서버가 사용자의 agent를 사용하여 추가 인증을 수행할 수 있습니다. 따라서 완전히 신뢰할 수 있는 서버에만 이 기능을 활성화하고, 기본적으로는 비활성화 상태를 유지하십시오.

Rotating and revoking: the lost laptop drill

일반 SSH key를 무효화하는 작업은 해당 key가 포함된 모든 server의 authorized_keys에서 해당 라인을 삭제하는 것뿐입니다. 통지할 certificate authority가 없으며 만료 날짜를 기다릴 필요도 없습니다. 라인이 삭제되는 즉시 해당 key를 사용한 새로운 로그인은 실패합니다.

비상 상황이 아닐 때 지금 바로 연습해 보십시오. server를 하나 선택하고 ~/.ssh/authorized_keys을 열어 comment를 통해 key를 찾으십시오. editor로 해당 라인을 삭제하거나 comment를 사용하여 필터링하십시오.

grep -v ' laptop$' ~/.ssh/authorized_keys > ~/.ssh/authorized_keys.tmp
mv ~/.ssh/authorized_keys.tmp ~/.ssh/authorized_keys

그 다음, 방금 무효화한 device에서는 로그인이 실패하는지 확인하고, 다른 device에서는 로그인이 여전히 작동하는지 확인하십시오. 한 가지 주의할 점이 있습니다. key는 로그인 시에만 확인되므로, key를 삭제해도 이미 연결된 session은 종료되지 않습니다. 분실된 device의 권한을 무효화하는 경우, server의 who도 확인하여 알 수 없는 session을 모두 종료하십시오.

Rotation은 순서만 바뀐 동일한 작업입니다. device에서 새로운 key를 생성하고, ssh-copy-id을 사용하여 설치한 뒤, 새로운 key로 로그인이 되는지 확인하고, 마지막으로 기존 라인을 삭제하십시오. 이 작업은 device의 소유자가 변경될 때, key가 노출되었을 가능성이 있을 때, 또는 팀원이 퇴사할 때 수행하십시오. server 2대에서 이 작업을 수동으로 하는 것은 괜찮으나, 20대 이상의 server라면 자동화가 필요합니다. managing multiple Linux servers에서 전체 fleet에 동일한 authorized_keys 상태를 적용하는 방법을 확인할 수 있습니다.

주의 사항

• 모든 기기에 하나의 private key를 공유하지 마십시오. 기기 하나를 분실했을 때 해당 키를 모든 곳에서 교체하지 않고는 무효화할 수 없습니다.

• private key를 git repository에 커밋하지 마십시오. private repository라도 마찬가지입니다. 자동 스캐너는 public repository를 감시하며, push 후 몇 분 이내에 유출된 키를 탐지합니다. 또한 나중에 repository가 public으로 전환되면 전체 이력이 유출됩니다.

• 서버 간 통신을 위해 노트북의 private key를 서버에 업로드하지 마십시오. 서버 자체에서 별도의 키를 생성하고, 필요한 곳에만 해당 키를 등록하십시오.

• chat, email 또는 ticket에 private key를 붙여넣지 마십시오. 공유해야 하는 것은 public key인 .pub 파일뿐입니다.

키를 통한 로그인이 안정적으로 작동하면, password authentication을 비활성화하십시오. 이렇게 하면 서버를 대상으로 한 무차별 대입 공격을 완전히 차단할 수 있습니다. 관련 설정 방법은 SSH hardening on a VPS를 참조하십시오.

FAQ

비밀번호를 전송하지 않고 SSH key가 작동하는 방식은 무엇입니까?

서버는 ~/.ssh/authorized_keys에 사용자의 public key를 저장합니다. 로그인 시 서버가 challenge를 보내면, client가 private key로 해당 challenge에 서명합니다. 서버는 public key로 이 서명을 검증합니다. private key는 장치를 벗어나지 않으므로 전송 중에 가로챌 데이터가 없으며, 서버에서 탈취할 재사용 가능한 정보도 없습니다. 서버가 침해되어도 public key만 유출될 뿐이며, 이는 다른 곳에 로그인하는 데 사용할 수 없습니다.

모든 서버에 동일한 SSH key를 사용해도 됩니까?

하나의 key를 여러 서버에서 사용하는 것은 올바른 방법입니다. 단, 해당 key가 단일 장치에만 보관되어야 합니다. 규칙은 서버당 하나의 key가 아니라, 장치당 하나의 key를 사용하는 것입니다. 예를 들어, laptop의 public key는 해당 laptop이 접속해야 하는 모든 서버에 등록하며, desktop은 별도의 key를 가집니다. 이렇게 하면 키 무효화(revocation)가 간단해집니다. 장치를 분실했을 때 각 서버에서 해당 식별 라인 하나만 제거하면 되며, 다른 장치들은 계속 작동하기 때문입니다.

.ssh 디렉토리와 authorized_keys의 권한은 어떻게 설정해야 합니까?

~/.ssh에는 700를, 600에는 authorized_keys 및 모든 private key에 authorized_keys를 설정하십시오. 소유자는 해당 키를 사용하는 계정이어야 합니다. sshd는 기본적으로 StrictModes yes 권한으로 실행됩니다. 따라서 본인 이외의 사용자가 쓰기 권한을 가진 파일이나 home directory가 있으면 sshd는 키를 무시하며, 이 경우 서버의 auth log 또는 journal에 Authentication refused: bad ownership or modes만 남게 됩니다.

서버에서 SSH key를 어떻게 제거합니까?

해당 키가 권한을 가졌던 계정의 ~/.ssh/authorized_keys 파일에서 해당 키 라인을 삭제하십시오. 키 데이터 뒤에 오는 주석(comment)을 통해 올바른 라인을 찾을 수 있습니다. 해당 키를 이용한 새로운 로그인은 즉시 실패하지만, 이미 연결된 세션은 유지됩니다. 따라서 장치를 분실했다면 실행 중인 세션도 종료하십시오. 키가 복사되었던 모든 서버에서 이 작업을 반복하십시오.

SSH key에 passphrase를 설정해야 합니까?

laptop이나 desktop에서 사용하는 키라면 설정해야 합니다. passphrase는 키 파일을 암호화하므로, 키 파일이 유출되더라도 그 자체로는 사용할 수 없습니다. 또한 ssh-agent을 사용하면 매 연결마다 입력하는 대신 세션당 한 번만 입력하면 됩니다. 서버에서 자동화 도구(unattended automation)가 사용하는 키는 입력할 사람이 없으므로 보통 passphrase가 없습니다. 이러한 키는 대상 계정의 권한을 제한하는 방식으로 보호하십시오.