SSH 키 생성 및 관리 방법: ed25519 권장 가이드

SSH 키의 작동 원리

SSH 키는 한 쌍의 파일로 구성됩니다. 개인 키(private key)는 사용자의 장치에 보관하고, 공개 키(public key)는 로그인하려는 모든 서버에 복사합니다. 연결을 시도하면 서버는 공개 키를 사용하여 대응하는 개인 키만이 풀 수 있는 챌린지를 보냅니다. 개인 키는 장치를 벗어나지 않으므로 네트워크를 통해 비밀 정보가 전송되지 않으며, 서버가 침해되더라도 탈취할 만한 정보가 남지 않습니다. 이것이 바로 키 방식이 비밀번호보다 우수한 이유입니다. SSH 키를 올바르게 관리하려면 네 가지 습관이 필요합니다. 장치당 하나의 키 사용, sshd가 요구하는 파일 권한 설정, 옵션 입력을 줄여주는 ~/.ssh/config 파일 활용, 그리고 노트북 분실 시 즉시 키를 제거하는 방법 숙지가 그것입니다.

이 가이드는 Ubuntu 24.04를 기준으로 각 습관을 다루지만, 여기에 포함된 내용은 대부분 모든 Linux 서버와 최신 OpenSSH 환경에 동일하게 적용됩니다.

시작하기 전에 실수를 방지하기 위해 용어 하나를 명확히 하겠습니다. 공개 키는 비밀이 아닙니다. 티켓에 붙여넣거나 이메일로 보내거나 공개해도 누구도 그 키만으로는 로그인할 수 없습니다. 비밀인 것은 개인 키입니다. 이 파일을 복사하고 암호(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을 그대로 사용하십시오. 이어서 암호(passphrase)를 묻습니다. 암호를 설정하십시오. 아래의 암호 관련 섹션에서 일상적인 사용에 지장이 없는 이유를 설명합니다. 작업이 끝나면 두 개의 파일이 생성됩니다. ~/.ssh/id_ed25519는 개인 키(private key)이며, ~/.ssh/id_ed25519.pub은 공개 키(public key)입니다. 공개 키의 내용을 확인하십시오.

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

이 내용은 키 유형, 키 데이터, 주석으로 구성된 한 줄의 텍스트입니다. 이 한 줄이 서버에 등록될 내용입니다.

서버당 하나가 아닌, 기기당 하나의 키 사용

가장 먼저 하는 질문은 "서버마다 새로운 키가 필요한가?"입니다. 그렇지 않습니다. 사용하는 기기마다 키를 하나씩 생성하고, 해당 기기가 접속해야 하는 모든 서버에 그 공개 키를 등록하십시오. 키는 기기를 식별하는 역할을 합니다. 각 서버의 authorized_keys 파일은 접속이 허용된 기기들의 목록입니다.

이 모델은 확장성이 뛰어나며, 다른 방식들은 예상 가능한 문제들을 일으킵니다. 서버당 하나의 키를 사용하는 방식은 노트북에 20개의 서버를 위한 20개의 개인 키를 보관하게 만들며, 결국 어떤 키가 무엇인지 파악할 수 없게 됩니다. 모든 기기가 하나의 키를 공유하는 방식은 더 위험합니다. 노트북을 도난당했을 때, 데스크톱도 같은 개인 키를 가지고 있으므로 데스크톱까지 차단하지 않고는 노트북의 접근 권한만 취소할 수 없습니다. 따라서 모든 곳의 키를 교체하고 모든 기기에 즉시 다시 배포해야 합니다.

기기당 하나의 키를 사용하면, 노트북을 분실했을 때 서버당 한 줄만 삭제하면 됩니다. authorized_keys에서 해당 노트북의 줄을 삭제하면 다른 모든 기기는 계속 정상적으로 작동합니다. -C으로 설정한 주석은 해당 줄을 쉽게 찾을 수 있게 해줍니다.

이 모델의 기본 원칙은 다음과 같습니다. 개인 키는 기기에서 생성되어 해당 기기와 운명을 같이해야 합니다. 개인 키를 다른 기기로 복사하거나 서버에 업로드하지 마십시오. 새로운 기기에 접근 권한이 필요하면, 그 기기에서 새로운 키를 생성하십시오.

서버에 공개 키 배치하기

가장 쉬운 방법은 OpenSSH와 함께 배포되는 ssh-copy-id를 사용하는 것입니다.

ssh-copy-id matt@10.0.0.10

이 명령은 현재 사용 가능한 인증 방식(보통 비밀번호)으로 로그인한 뒤, 서버의 ~/.ssh/authorized_keys 파일에 공개 키를 추가합니다. 만약 디렉터리나 파일이 없다면 올바른 권한으로 새로 생성합니다. 새로운 SSH 세션을 열어 테스트해 보십시오. 서버가 계정 비밀번호를 묻지 않고 접속을 허용해야 합니다. 키에 암호(passphrase)가 설정되어 있다면 로컬 컴퓨터에서 이를 요구할 수 있는데, 이는 서버 비밀번호가 아닌 로컬에서 발생하는 인증 과정입니다.

비밀번호 로그인이 이미 비활성화된 상태라면 ssh-copy-id은 접속할 수 없으므로, 직접 한 줄을 추가해야 합니다. 현재 접속 가능한 세션이나 제공업체의 웹 콘솔을 통해 서버에 로그인한 뒤 다음 명령을 실행하십시오.

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

따옴표 안에 실제 공개 키를 붙여 넣으십시오. id_ed25519.pub에 있는 전체 한 줄을 그대로 사용해야 합니다. authorized_keys은 한 줄에 하나의 공개 키만 허용하며, 이것이 전체 접근 제어 데이터베이스 역할을 합니다. 기기를 추가하려면 한 줄을 덧붙이고, 접근을 취소하려면 해당 줄을 삭제하면 됩니다. 새로 생성한 서버라면 이 단계는 새 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 파일이 없습니다. 동일한 로그 메시지는 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은 혼란스러운 오류를 해결해주므로 별도로 설명할 가치가 있습니다. 에이전트에 여러 개의 키가 로드되어 있으면 클라이언트는 이를 하나씩 시도하는데, 서버는 각 시도를 실패한 접속 시도로 간주합니다. 키가 너무 많으면 올바른 키를 시도하기도 전에 Received disconnect: Too many authentication failures 오류가 발생합니다. IdentitiesOnly yes를 설정하면 클라이언트는 IdentityFile에 지정된 키만 제공하므로 이러한 실패가 발생하지 않습니다.

Passphrase와 ssh-agent

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

실무에서 Passphrase를 사용해도 불편함이 없는 이유는 ssh-agent 덕분입니다. Agent는 복호화된 키를 메모리에 보관하므로, 로그인 세션당 한 번만 Passphrase를 입력하면 이후의 모든 연결은 즉시 이루어집니다. 대부분의 데스크톱 Linux 배포판과 macOS는 이미 Agent를 실행하고 있습니다. 다음 명령어로 키를 Agent에 등록하십시오.

ssh-add ~/.ssh/id_ed25519

ssh-add -l는 현재 Agent가 보유한 키 목록을 보여줍니다. 주의할 점이 하나 있습니다. Agent forwarding(ssh -A)을 사용하면 원격 서버에 접속해 있는 동안 해당 서버가 사용자의 Agent를 사용하여 추가 인증을 수행할 수 있습니다. 따라서 완전히 신뢰하는 서버에만 이 기능을 활성화하고, 기본적으로는 비활성화 상태로 두어야 합니다.

키 교체 및 폐기: 노트북 분실 시 대응 훈련

일반 SSH 키를 폐기하는 작업은 모든 서버의 authorized_keys에서 해당 키가 포함된 줄을 삭제하는 것뿐입니다. 통보해야 할 인증 기관도 없고, 만료일을 기다릴 필요도 없습니다. 해당 줄이 삭제되는 즉시 해당 키를 사용한 새로운 로그인은 실패합니다.

비상 상황이 아닐 때 지금 바로 훈련을 수행하십시오. 서버 하나를 선택하여 ~/.ssh/authorized_keys을 열고 주석을 통해 키를 찾으십시오. 편집기로 해당 줄을 삭제하거나 주석을 기준으로 필터링하여 제거하십시오:

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

그런 다음 방금 폐기한 장치에서 로그인이 실패하는지, 다른 장치에서는 여전히 로그인이 잘 되는지 확인하십시오. 한 가지 세부 사항을 유의하십시오. 키는 로그인 시점에만 확인하므로, 키를 삭제해도 이미 열려 있는 세션은 종료되지 않습니다. 도난당한 장치의 접근 권한을 폐기하는 경우, 서버에서 who도 확인하여 인식할 수 없는 세션을 모두 종료하십시오.

키 교체는 순서만 다를 뿐 동일한 작업입니다. 장치에서 새 키를 생성하고 ssh-copy-id으로 설치한 뒤, 새 키로 로그인이 되는지 확인하고 마지막으로 이전 키가 적힌 줄을 삭제하십시오. 장치 사용자가 바뀌거나, 키가 노출되었을 가능성이 있거나, 팀원이 퇴사할 때 이 작업을 수행하십시오. 서버 두 대 정도라면 수동으로 해도 괜찮지만, 스무 대가 넘어가면 자동화가 필요합니다. 여러 대의 Linux 서버 관리하기에서는 동일한 authorized_keys 상태를 전체 서버군에 배포하는 방법을 다룹니다.

하지 말아야 할 작업

• 모든 기기에서 하나의 private key를 공유하지 마십시오. 기기를 분실했을 때 해당 키를 모든 곳에서 교체하지 않으면 도난당한 기기의 접근 권한을 취소할 수 없습니다.

• private repository라 하더라도 git 저장소에 private key를 커밋하지 마십시오. 자동화된 스캐너가 public repository를 감시하며 push 후 수 분 내에 유출된 키를 시도합니다. 나중에 repository가 public으로 전환되면 전체 기록이 유출됩니다.

• 한 서버가 다른 서버에 접근할 수 있도록 노트북의 private key를 서버에 업로드하지 마십시오. 서버 자체에서 별도의 키를 생성하고, 필요한 곳에만 해당 키를 승인하십시오.

• 채팅, 이메일, 티켓 등에 private key를 붙여넣지 마십시오. 공유할 수 있는 유일한 정보는 public key인 .pub 파일뿐입니다.

키를 통해 로그인이 안정적으로 이루어지면, 다음 단계로 비밀번호 인증을 비활성화하십시오. 이를 통해 서버를 대상으로 하는 지속적인 무차별 대입 공격을 완전히 차단할 수 있습니다. 관련 설정은 SSH hardening on a VPS에서 확인할 수 있습니다.

FAQ

SSH 키는 비밀번호를 전송하지 않고 어떻게 작동합니까?

서버는 사용자의 공개 키를 ~/.ssh/authorized_keys에 보관합니다. 로그인 시 서버는 챌린지를 보내고, 클라이언트는 개인 키로 해당 챌린지에 서명하며, 서버는 공개 키로 서명을 검증합니다. 개인 키는 사용자의 장치를 절대 떠나지 않으므로 전송 중에 가로챌 수 있는 정보가 없으며, 서버에서 훔쳐서 재사용할 수 있는 정보도 없습니다. 서버가 침해당하더라도 공개 키만 유출될 뿐이며, 이는 어디에서도 로그인에 사용할 수 없습니다.

모든 서버에 동일한 SSH 키를 사용해야 합니까?

키가 단일 장치에만 보관된다면 여러 서버에 하나의 키를 사용하는 것은 올바른 방법입니다. 규칙은 서버당 하나가 아니라 장치당 하나입니다. 노트북의 공개 키를 필요한 모든 서버에 등록하고, 데스크톱은 별도의 키를 사용하십시오. 이렇게 하면 키 폐기가 간편해집니다. 장치를 분실했을 때 각 서버에서 해당 장치의 식별 가능한 줄 하나만 삭제하면 되며, 다른 장치들은 계속 정상적으로 작동합니다.

.ssh 디렉터리와 authorized_keys에는 어떤 권한을 설정해야 합니까?

~/.ssh에는 700를, authorized_keys 및 모든 개인 키에는 600을 설정하십시오. 소유자는 해당 키를 사용하는 계정이어야 합니다. sshd는 기본적으로 StrictModes yes로 실행되므로, 사용자 외에 다른 사람이 쓰기 권한을 가진 파일이나 홈 디렉터리가 있으면 sshd는 해당 키를 무시합니다. 이때 유일한 흔적은 서버의 인증 로그나 저널에 남는 Authentication refused: bad ownership or modes뿐입니다.

서버에서 SSH 키를 제거하려면 어떻게 해야 합니까?

인증된 계정의 ~/.ssh/authorized_keys에서 해당 키가 포함된 줄을 삭제하십시오. 키 데이터 뒤에 있는 레이블인 주석을 통해 올바른 줄을 찾을 수 있습니다. 해당 키를 사용한 새로운 로그인은 즉시 실패하지만, 이미 열려 있는 세션은 유지되므로 장치를 도난당했다면 활성 세션도 종료하십시오. 키가 복사된 모든 서버에서 이 과정을 반복하십시오.

SSH 키에 암호(passphrase)가 필요합니까?

노트북이나 데스크톱에 저장된 키라면 필요합니다. 암호는 키 파일을 암호화하므로, 키 파일이 도난당하거나 유출되어도 그 자체로는 쓸모가 없습니다. 또한 ssh-agent을 사용하면 매번 연결할 때마다 암호를 입력할 필요 없이 세션당 한 번만 입력하면 됩니다. 서버에서 무인 자동화 작업에 사용하는 키는 일반적으로 암호를 설정하지 않습니다. 사람이 직접 암호를 입력할 수 없기 때문입니다. 이러한 키는 대상 계정이 수행할 수 있는 작업을 제한하여 보호하십시오.