리눅스 ssh 키 생성 총정리

리눅스 ssh 키 생성은 ssh-keygen으로 개인키와 공개키를 한 쌍 만들고, 공개키만 서버의 authorized_keys에 등록하는 흐름으로 끝납니다. 처음에는 ed25519를 기본으로 검토하고, 기존 장비나 외부 시스템과의 호환성이 필요할 때 RSA를 비교해 선택해요. 아래에서는 키 종류 선택부터 생성, 권한 설정, 서버 등록, 문제 확인까지 운영에 필요한 순서로 설명해요.

한눈에 보기

ssh 키 인증의 핵심은 “개인키는 내 작업 환경에만 두고, 공개키만 서버에 배포한다”는 원칙이에요. 공개키는 서버의 ~/.ssh/authorized_keys에 들어가고, 개인키는 접속을 시도하는 클라이언트가 가지고 있어야 해요. 이 둘의 역할을 헷갈리면 키를 잘못 복사하거나 권한을 느슨하게 두는 실수가 생기기 쉬워요.

운영 환경에서 자주 쓰는 흐름은 다음과 같아요.

• 키 종류 결정: 신규 환경은 ed25519를 우선 검토하고, 레거시 장비 연동은 RSA를 비교해요.
• 키 쌍 생성: ssh-keygen -t ed25519 -C "ops@example.com"를 실행해요.
• 공개키 확인: cat ~/.ssh/id_ed25519.pub로 .pub 파일 내용을 확인해요.
• 서버 등록: ssh-copy-id -i ~/.ssh/id_ed25519.pub user@host를 사용하거나 공개키를 직접 추가해요.
• 권한 정리: ~/.ssh와 authorized_keys, 개인키 권한을 각각 점검해요.
• 접속 확인: ssh -i ~/.ssh/id_ed25519 user@host로 인증이 되는지 확인해요.

이 흐름은 단일 서버에 접속할 때도 그대로 적용되고, 배포 자동화나 점프 호스트를 운영할 때도 기본 개념은 같아요. 다만 자동화에서는 키를 어디에 보관하고 어떤 계정에 연결할지까지 함께 설계해야 해요.

키 종류 비교

키 종류는 “무조건 최신 알고리즘”이 아니라 “서버와 클라이언트가 함께 지원하는가”를 기준으로 선택해야 해요. OpenSSH 환경에서는 ed25519가 일반적인 선택지이고, 오래된 장비나 특정 솔루션과 연동해야 할 때 RSA가 여전히 쓰여요. ECDSA는 조직의 표준이나 기존 정책이 있을 때 검토할 수 있어요.

ed25519가 모든 환경에서 정답은 아니에요. 서버의 OpenSSH 버전, 접속을 허용해야 하는 외부 서비스, 조직의 보안 기준을 함께 확인해야 해요. 호환성 문제가 없다면 ed25519를 먼저 선택하고, 오래된 장비나 특정 벤더 장비와 연동해야 한다면 RSA를 검토하는 방식이 현실적이에요.

키를 새로 만드는 시점에는 기존 키를 덮어쓰지 않도록 저장 경로를 확인하는 것도 중요해요. ssh-keygen은 기본 경로에 파일이 이미 있으면 덮어쓸지 물어보므로, 운영 키를 관리하는 디렉터리라면 특히 주의해야 해요.

단계별 생성 방법

키 쌍 만들기

터미널에서 ssh-keygen -t ed25519 -C "ops@example.com"를 실행해요. -C에는 키를 식별할 주석을 넣는데, 개인 이메일 대신 운영용 별칭을 쓰면 나중에 키를 추적하기 쉬워요. 실행하면 저장 경로와 패스프레이즈를 묻고, 기본 경로를 그대로 사용하면 ~/.ssh/id_ed25519와 ~/.ssh/id_ed25519.pub가 만들어져요.

패스프레이즈는 비워 둘 수도 있지만, 개인키 파일이 유출됐을 때를 대비해 설정하는 편이 안전해요. 자동 배포처럼 사람이 매번 입력할 수 없는 환경이라면 패스프레이즈 없는 키를 쓰기보다, 전용 배포 키와 제한된 권한, 시크릿 저장소를 함께 설계하는 편이 좋아요.

공개키 확인

cat ~/.ssh/id_ed25519.pub로 공개키를 확인해요. 출력은 ssh-ed25519로 시작하고 끝에 주석이 붙는 형태예요. 이 내용은 서버에 등록해도 되지만, .pub가 붙지 않은 id_ed25519 파일은 개인키이므로 절대 공유하거나 서버에 올리면 안 돼요.

공개키를 복사할 때는 줄바꿈이 깨지지 않도록 주의해야 해요. authorized_keys에 여러 키가 들어갈 수 있으므로, 기존 내용을 지우지 않고 필요한 공개키를 추가하는 방식으로 관리해요.

서버에 등록

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@host를 사용하면 공개키를 원격 계정의 ~/.ssh/authorized_keys에 추가할 수 있어요. ssh-copy-id가 없거나 정책상 직접 배포해야 한다면 공개키 내용을 복사해 원격 서버의 ~/.ssh/authorized_keys에 추가해요. 이때 원격 계정의 홈 디렉터리와 .ssh 디렉터리 권한도 함께 정리해야 해요.

서버에 등록하는 것은 공개키라는 점을 다시 확인해요. 개인키를 서버에 복사하면 서버가 침해됐을 때 다른 서버로 이동할 수 있는 발판이 될 수 있어요. 운영에서는 “서버에는 공개키만, 클라이언트에는 개인키만”을 기본 원칙으로 두는 편이 안전해요.

권한 정리

권한은 ssh 키 인증에서 자주 놓치는 부분이에요. 로컬에서는 chmod 700 ~/.ssh, chmod 600 ~/.ssh/id_ed25519를 적용하고, 서버에서는 chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys를 확인해요. 권한이 느슨하면 OpenSSH가 키를 무시하거나 인증을 거부할 수 있어요.

서버 쪽에서는 홈 디렉터리 권한도 점검해야 해요. 홈 디렉터리가 다른 사용자에게 쓰기 가능하면 키 인증이 실패할 수 있어요. 권한 외에도 SELinux나 홈 디렉터리 마운트 옵션, sshd 설정이 영향을 줄 수 있으므로 인증 실패가 반복되면 로그와 설정을 함께 확인해요.

접속 확인

ssh -i ~/.ssh/id_ed25519 user@host로 접속해요. 접속에 성공하면 ~/.ssh/config에 Host 별칭을 등록해 명령을 짧게 만들 수 있어요. 예를 들어 Host ops-server, HostName server.example.com, User deploy, IdentityFile ~/.ssh/id_ed25519 같은 항목을 설정하면 ssh ops-server로 접속할 수 있어요.

실패할 때는 ssh -v user@host로 어느 단계에서 거부되는지 확인해요. 키 파일을 찾지 못하는지, 권한 때문에 무시되는지, 서버의 authorized_keys에 키가 없는지, 호스트 키 확인에서 멈추는지 구분하면 원인을 좁힐 수 있어요.

ssh-agent와 키 관리

ssh-agent는 패스프레이즈를 매번 입력하지 않도록 개인키를 메모리에 보관하는 도구예요. eval "$(ssh-agent -s)"로 에이전트를 시작하고 ssh-add ~/.ssh/id_ed25519로 키를 등록해요. 등록된 키는 ssh-add -l로 확인할 수 있어요.

에이전트 포워딩은 편리하지만, 침투당한 원격 호스트가 에이전트를 통해 다른 서버에 접근할 수 있는 위험이 있어요. 꼭 필요한 경우가 아니라면 ForwardAgent no를 기본으로 두고, 점프 호스트를 운영한다면 접근 범위와 세션 정책을 함께 제한하는 편이 안전해요.

키를 교체할 때는 새 키를 만든 뒤 공개키를 서버에 추가하고, 접속이 정상인 것을 확인한 다음 기존 공개키를 제거해요. 이 순서를 지키면 교체 중에 접속이 끊기는 상황을 줄일 수 있어요. 퇴사자나 외부 협력사가 사용한 키는 별도 목록으로 관리하고, 사용이 끝나면 서버의 authorized_keys에서 즉시 제거해야 해요.

상황별 선택

신규 리눅스 서버에 접속하는 일반 운영 환경이라면 ed25519를 먼저 검토해요. 키 길이가 짧고 관리가 단순하며, 최신 OpenSSH 환경에서 무난하게 사용할 수 있어요. 다만 서버 이미지가 오래됐거나 접속 대상이 특정 장비라면 지원 알고리즘을 먼저 확인해야 해요.

오래된 장비나 네트워크 장비, 외부 솔루션과 연동해야 한다면 RSA를 검토해요. RSA는 -b 옵션으로 키 길이를 지정할 수 있지만, 무조건 긴 키를 쓰기보다 대상 시스템이 지원하는 범위와 조직의 기준을 확인해야 해요. ECDSA는 조직 표준이 있거나 기존 키 체계를 유지해야 할 때 선택해요.

배포 자동화에서는 사람이 사용하는 키와 자동화용 키를 분리하는 편이 좋아요. 자동화 키는 시크릿 저장소에 보관하고, 배포 계정의 권한을 최소화하며, 가능하면 제한된 명령만 실행할 수 있도록 서버 설정을 함께 검토해요. 여러 서버에 같은 공개키를 등록할 수 있지만, 서버별로 키를 분리하면 폐기와 추적이 쉬워져요.

주의할 점

• 개인키는 절대 서버나 코드 저장소에 올리지 않아요.
• authorized_keys와 .ssh 디렉터리 권한을 함께 점검해요.
• 패스프레이즈를 설정했다면 분실 시 복구가 어렵다는 점을 기억해요.
• 호스트 키가 바뀌면 무조건 무시하지 말고 변경 원인을 확인해요.
• 퇴사자나 외부 협력사가 사용한 공개키는 서버에서 제거해요.
• 에이전트 포워딩은 필요한 경우에만 제한적으로 사용해요.
• 키를 교체할 때는 새 키 접속을 확인한 뒤 기존 키를 제거해요.

특히 authorized_keys는 여러 키가 누적되기 쉬운 파일이에요. 주석을 의미 있게 남기고, 정기적으로 사용하지 않는 키를 정리하면 사고 때 추적이 쉬워져요. 키를 삭제할 때는 해당 키로 접속 중인 세션이 없는지도 확인하는 편이 좋아요.

자주 묻는 질문

ssh-keygen 없이도 키를 만들 수 있나요?

리눅스에서는 OpenSSH의 ssh-keygen이 사실상 표준 도구예요. 다른 도구로 만든 키도 OpenSSH 형식과 호환되면 사용할 수 있지만, 운영 환경에서는 배포판에 포함된 ssh-keygen으로 만드는 편이 검증하기 쉬워요.

키 파일 이름을 바꾸면 접속이 안 되나요?

파일 이름 자체가 인증을 깨뜨리지는 않아요. 다만 ssh 클라이언트가 기본 이름을 찾지 못하므로 ~/.ssh/config의 IdentityFile이나 ssh -i로 경로를 지정해야 해요.

패스프레이즈를 잊으면 복구할 수 있나요?

패스프레이즈는 키를 암호화하는 값이라 복구 절차가 없어요. 잊었다면 새 키 쌍을 만들어 공개키를 서버에 다시 등록하고, 기존 공개키를 제거하는 편이 안전해요.

서버에 공개키를 추가했는데도 계속 비밀번호를 묻나요?

authorized_keys 경로와 권한, sshd 설정, 접속 계정의 홈 디렉터리 권한을 확인해요. ssh -v로 클라이언트가 어떤 키를 제시하는지 보고, 서버 로그에서 거부 이유를 함께 확인하면 원인을 좁힐 수 있어요.

출처

• OpenSSH ssh-keygen 매뉴얼: https://man.openbsd.org/ssh-keygen
• OpenSSH 매뉴얼 모음: https://www.openssh.com/manual.html
• GitHub Docs, Generating a new SSH key: https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-your-ssh-agent

서버 접근 권한을 정리하다 보면 파일 권한과 소유자 개념도 함께 필요해요. 관련 운영 글인 리눅스 파일 권한과 소유자 관리를 함께 읽어 보세요.