SSH 키 생성 및 관리편집자 확인

SSH 키는 한 쌍의 암호화된 키 파일로 구성된다. 이 쌍은 공개키와 개인키로 나뉜다. 공개키는 공유해도 안전한 키이며, 주로 원격 서버에 등록하는 데 사용된다. 반면 개인키는 절대 외부에 공개되지 않아야 하는 비밀 키로, 사용자의 로컬 머신에 안전하게 보관된다. 이 두 키는 수학적으로 연결되어 있어, 공개키로 암호화된 데이터는 오직 대응되는 개인키로만 복호화할 수 있다.

SSH 접속 과정에서 이 키 쌍의 역할은 다음과 같다. 클라이언트가 서버에 접속을 시도하면, 서버는 클라이언트가 등록해둔 공개키를 사용하여 임의의 챌린지 메시지를 암호화하여 전송한다. 클라이언트는 자신의 로컬에 저장된 개인키를 사용하여 이 메시지를 복호화하고, 그 결과를 서버로 되돌려 보낸다. 서버는 응답을 확인하여 클라이언트의 신원을 인증한다. 이 방식은 암호를 네트워크를 통해 전송하지 않기 때문에 중간자 공격에 더 강력하다.

공개키와 개인키의 파일 형식과 저장 위치는 일반적으로 다음과 같다.

개인키 파일의 소유권과 파일 권한은 보안상 매우 중요하다. 일반적으로 해당 파일의 권한은 소유자만 읽고 쓸 수 있도록 600 (rw-------)으로 설정되어야 한다. 부적절한 권한 설정은 SSH 클라이언트가 보안 위험을 이유로 키 사용을 거부하는 원인이 된다.

SSH 키 생성 시 사용할 수 있는 주요 암호화 알고리즘에는 RSA, ECDSA, Ed25519 등이 있습니다. 각 알고리즘은 서로 다른 수학적 원리와 보안 강도, 성능 특성을 가집니다.

RSA는 역사가 길고 모든 시스템에서 광범위하게 지원되지만, 최신 알고리즘에 비해 상대적으로 키 크기가 커서 연결 설정 시 부하가 더 클 수 있습니다. Ed25519는 2014년 OpenSSH 6.5에 도입되었으며, 부채널 공격에 대한 내성과 일정한 시간 내 연산 실행 등 보안적 이점으로 인해 새로운 키 생성 시 점점 더 선호되는 방식이 되고 있습니다[3]. ECDSA는 타원곡선의 이점을 활용하지만, 구현에 따라 난수 생성기의 결함이 보안 취약점으로 이어질 수 있는 위험이 있습니다.

알고리즘 선택은 호환성 요구사항과 보안 목표에 따라 달라집니다. 레거시 시스템과의 호환성이 중요하다면 RSA를, 최신 시스템에서 최적의 보안과 성능을 원한다면 Ed25519를 선택하는 것이 일반적입니다.

ssh-keygen 명령어는 SSH 키 쌍을 생성하는 데 사용되는 표준 도구이다. 이 명령어는 대부분의 유닉스 계열 운영체제(리눅스, macOS)와 윈도우의 WSL 또는 Git for Windows 환경에 기본적으로 포함되어 있다.

명령어의 기본적인 사용법은 터미널에서 ssh-keygen을 입력하는 것이다. 이렇게 하면 대화형 모드로 진입하여 키를 저장할 파일 경로와 패스프레이즈를 차례로 입력받는다. 기본값을 사용하려면 각 단계에서 엔터 키를 누르면 된다. 기본적으로 RSA 알고리즘과 3072비트 길이의 키가 생성되며, 공개키와 개인키 쌍이 사용자의 ~/.ssh 디렉토리(id_rsa와 id_rsa.pub)에 저장된다.

보다 세부적인 옵션을 지정하여 키를 생성할 수도 있다. 주요 옵션은 다음과 같다.

예를 들어, 4096비트 길이의 RSA 키를 my_key라는 이름으로 생성하면서 코멘트를 추가하려면 다음 명령을 사용한다.

```bash

ssh-keygen -t rsa -b 4096 -f ~/.ssh/my_key -C "user@example.com"

```

명령 실행 후에는 개인키(my_key)와 공개키(my_key.pub) 파일이 지정된 위치에 생성된다.

ssh-keygen 명령어를 실행할 때 -t 옵션으로 키의 암호화 방식을 지정할 수 있다. 주요 키 유형으로는 RSA, ECDSA, Ed25519 등이 있으며, 각각 보안 강도와 성능 특성이 다르다. -b 옵션을 사용하면 키의 길이(비트 수)를 설정할 수 있으며, 키 유형에 따라 권장되는 길이가 다르다.

다음은 주요 키 유형과 권장 길이, 그리고 간단한 특징을 비교한 표이다.

키 유형 선택은 보안, 성능, 그리고 호환성의 균형을 고려해야 한다. Ed25519는 현대적이고 안전하며 빠른 알고리즘으로, 지원하는 시스템에서는 권장되는 선택이다. 레거시 시스템과의 호환성이 가장 중요한 경우에는 RSA 3072비트 이상을 사용하는 것이 일반적이다. 키 길이는 보안 강도와 직접적으로 연관되며, 길이가 길수록 보안은 강화되지만 연결 설정 시 연산 부하가 약간 증가할 수 있다.

패스프레이즈는 SSH 키의 개인키 파일을 암호화하는 데 사용되는 추가 비밀번호이다. 패스프레이즈를 설정하면 개인키 파일이 유출되더라도 해당 암호를 모르는 제3자는 키를 사용할 수 없다. 이는 물리적 보안이 취약한 개인 컴퓨터 환경에서 특히 중요한 보안 계층을 추가한다.

패스프레이즈는 ssh-keygen 명령어를 실행하여 키를 생성하는 과정 중에 설정할 수 있다. 명령어를 실행하면 터미널에 "Enter passphrase (empty for no passphrase):"라는 프롬프트가 나타나며, 여기에 원하는 암호를 입력하면 된다. 보안을 위해 암호는 화면에 표시되지 않는다. 이후 동일한 암호를 확인하는 프롬프트가 한 번 더 나타난다. 공백으로 두고 Enter 키를 누르면 패스프레이즈 없이 키를 생성할 수 있지만, 이는 보안상 권장되지 않는다.

효과적인 패스프레이즈는 길고 예측하기 어려워야 한다. 무작위 단어 조합이나 긴 문장을 사용하는 것이 일반적인 단어나 짧은 암호보다 더 안전하다. 패스프레이즈는 키 파일 자체를 암호화하므로, 이후 SSH 에이전트 같은 도구를 사용하여 매번 입력하지 않고도 편리하게 관리할 수 있다. 에이전트에 키를 등록해 두면 세션 동안 한 번만 패스프레이즈를 입력하면 되며, 이를 통해 보안성과 사용 편의성을 동시에 확보할 수 있다.

원격 서버에 SSH 키 기반 인증을 설정하려면, 사용자의 공개키를 서버의 특정 파일에 등록해야 한다. 이 파일은 일반적으로 ~/.ssh/authorized_keys라는 이름과 경로를 가진다. 서버의 SSH 데몬은 클라이언트가 접속을 시도할 때, 이 파일에 등록된 공개키와 클라이언트가 제시하는 개인키 서명을 비교하여 인증을 수행한다.

authorized_keys 파일은 일반 텍스트 파일이며, 한 줄에 하나의 공개키를 기록한다. 각 줄은 키 유형(RSA, Ed25519 등), 공개키 자체, 그리고 선택적으로 주석으로 구성된다. 새로운 키를 추가하려면 기존 내용을 유지한 채, 새 공개키 문자열을 파일의 새로운 줄에 붙여넣기만 하면 된다. 파일이 존재하지 않을 경우 직접 생성할 수 있다.

이 파일의 권한 설정은 보안상 매우 중요하다. 과도하게 넓은 권한은 SSH 데몬이 인증을 거부하는 원인이 된다. 일반적으로 authorized_keys 파일의 권한은 소유자만 읽고 쓸 수 있는 600 (또는 최소 644)으로 설정되어야 하며, 상위 디렉토리인 ~/.ssh의 권한은 700으로 설정되어야 한다[5].

서버 관리자는 필요에 따라 authorized_keys 파일의 경로나 사용 가능한 키를 제한하는 등 SSH 데몬 설정(sshd_config)을 통해 인증 방식을 세부적으로 제어할 수 있다. 예를 들어, 특정 키에 대해 명령어 실행 제한을 부여하거나, 특정 IP 주소에서만 키 사용을 허용하는 옵션을 키 앞에 붙여서 설정할 수 있다.

ssh-copy-id는 공개키를 원격 서버에 자동으로 복사하고 등록하는 데 사용되는 편리한 명령줄 도구이다. 이 도구를 사용하면 사용자가 수동으로 공개키를 복사하여 ~/.ssh/authorized_keys 파일에 붙여넣는 과정을 자동화할 수 있다. ssh-copy-id는 기본적으로 대부분의 리눅스 및 macOS 시스템에 포함되어 있다.

명령어의 기본 사용법은 ssh-copy-id 사용자명@호스트명이다. 예를 들어, user라는 사용자 이름으로 example.com 서버에 키를 복사하려면 ssh-copy-id user@example.com을 실행한다. 이 명령을 실행하면, 도구는 기본적으로 로컬 시스템의 ~/.ssh/id_rsa.pub 파일에 있는 공개키를 찾아 지정된 원격 서버로 전송한다. 만약 다른 키 파일(예: ~/.ssh/id_ed25519.pub)을 사용하려면 -i 옵션을 통해 키 파일의 경로를 명시적으로 지정할 수 있다[6].

실행 과정은 다음과 같다.

1. 먼저 사용자에게 원격 서버의 비밀번호를 묻는다. 이는 초기 접속을 위한 비밀번호 인증이다.

2. 비밀번호 인증에 성공하면, 도구는 공개키 내용을 원격 서버의 해당 사용자 홈 디렉토리 아래 ~/.ssh/authorized_keys 파일에 추가한다.

3. 필요한 경우, 원격 서버의 ~/.ssh 디렉토리나 authorized_keys 파일이 존재하지 않으면 적절한 권한(700 또는 600)으로 생성한다.

이 도구의 주요 장점은 실수를 줄이고 표준화된 방식으로 키를 배포할 수 있다는 점이다. 수동으로 작업할 때 발생할 수 있는 줄바꿈 오류, 파일 권한 설정 누락, 잘못된 디렉토리에 키를 배치하는 문제 등을 자동으로 처리해 준다. 이후부터는 사용자는 비밀번호 없이 SSH 키 기반 인증을 사용하여 해당 서버에 접속할 수 있게 된다.

SSH 키 파일의 보안 권한 설정은 개인키가 무단으로 액세스되는 것을 방지하기 위한 필수 절차이다. SSH 클라이언트는 과도하게 개방된 권한을 가진 개인키 파일을 사용하는 연결을 거부하며, 이는 일반적인 보안 오류의 원인이 된다.

개인키 파일(id_rsa, id_ed25519 등)은 소유자만 읽고 쓸 수 있어야 하며, 그룹이나 다른 사용자에게는 어떠한 권한도 부여되어서는 안 된다. 권한은 숫자 모드 600 (rw-------)으로 설정하는 것이 표준이다. 공개키 파일(.pub 확장자)은 덜 제한적일 수 있지만, 일반적으로 644 권한으로 충분하다. 키가 저장된 ~/.ssh 디렉터리 자체도 다른 사용자의 접근을 차단하기 위해 700 (rwx------) 권한으로 설정하는 것이 좋다. 권한은 chmod 명령어를 사용하여 변경한다.

권한 문제가 발생하면 SSH 클라이언트는 "WARNING: UNPROTECTED PRIVATE KEY FILE!" 또는 "Permissions ... are too open"과 같은 경고 메시지를 출력하고 연결을 중단한다. 이 경우 ls -la ~/.ssh 명령으로 권한을 확인하고 chmod 명령으로 위 표에 명시된 적절한 권한으로 수정해야 한다. 이러한 엄격한 권한 검사는 키 파일이 실수로나 악의적으로 노출되는 위험을 크게 줄여준다.

패스프레이즈는 SSH 키의 개인키 파일을 암호화하는 추가 보안 계층이다. 키 생성 시 설정한 패스프레이즈를 변경하거나 완전히 제거할 수 있다. 이는 보안 요구사항 변경이나 편의성 향상을 위해 필요하다.

패스프레이즈를 변경하거나 제거하려면 ssh-keygen 명령어에 -p (change passphrase) 옵션을 사용한다. 명령어를 실행하면 기존 패스프레이즈를 입력한 후, 새로운 패스프레이즈를 두 번 입력하라는 프롬프트가 나타난다. 새로운 패스프레이즈를 빈칸으로 두고 엔터를 누르면 패스프레이즈가 제거된다. 이 작업은 키 파일 자체를 재암호화하거나 암호화를 해제한다.

패스프레이즈를 제거하면 키 파일 사용 시 매번 암호를 입력할 필요가 없어 편리해지지만, 개인키 파일이 유출될 경우 무단 접근의 위험이 증가한다. 반대로, 처음에 패스프레이즈 없이 생성한 키에 나중에 패스프레이즈를 추가하는 것도 동일한 명령어로 가능하다. 보안과 편의성 사이의 균형을 고려하여 결정하는 것이 중요하다.

하나의 시스템에서 여러 개의 SSH 키를 사용하여 서로 다른 서버나 서비스에 접근하는 경우가 흔하다. 예를 들어, 회사 서버용 키와 개인 깃허브 계정용 키를 분리하여 사용할 수 있다. 이때, 특정 호스트에 연결할 때 사용할 키를 지정하려면 ~/.ssh/config 파일을 구성하는 것이 효율적이다. 이 파일에서 호스트별로 사용할 개인키 파일 경로, 사용자명, 포트 등을 정의할 수 있다.

```

Host github.com

HostName github.com

User git

IdentityFile ~/.ssh/id_ed25519_github

IdentitiesOnly yes

Host company-server

HostName 192.168.1.100

User deploy

IdentityFile ~/.ssh/id_rsa_company

```

매번 패스프레이즈를 입력하는 번거로움을 해결하고 키를 안전하게 관리하기 위해 SSH 에이전트를 사용한다. SSH 에이전트는 인증 에이전트로서, 개인키를 메모리에 로드하고 암호화된 연결을 설정할 때 클라이언트를 대신하여 서명을 처리한다. 에이전트를 시작하고 키를 추가하는 일반적인 명령어는 다음과 같다.

```bash

eval "$(ssh-agent -s)"

ssh-add ~/.ssh/id_ed25519_github

```

ssh-add 명령어를 실행하면 해당 키의 패스프레이즈를 한 번만 입력하면 되며, 이후에는 에이전트가 세션 동안 인증을 대행한다. 현재 에이전트가 관리 중인 키 목록을 확인하려면 ssh-add -l 명령어를 사용한다. 세션을 종료하면 에이전트 프로세스도 종료되어 메모리에서 키가 제거되므로 보안상 안전하다. 일부 운영체제의 데스크톱 환경은 로그인 시 자동으로 SSH 에이전트를 시작하고 키를 추가하기도 한다.

SSH 접속 시 발생하는 가장 흔한 오류 중 하나는 키 파일의 파일 시스템 권한이 지나치게 느슨할 때 나타나는 "Bad permissions" 또는 "Permissions too open" 오류이다. SSH 프로토콜은 보안상의 이유로 개인키 파일(id_rsa, id_ed25519 등)이 소유자 외 다른 사용자에게 쓰기 또는 읽기 권한이 부여되는 것을 엄격히 금지한다.

일반적으로 개인키 파일은 소유자만 읽을 수 있는 600 (-rw-------) 권한이어야 한다. 공개키 파일(id_rsa.pub 등)과 ~/.ssh 디렉토리 자체도 다른 사용자가 쓰기 권한을 가지지 않도록 설정하는 것이 안전하다. 권한 문제를 해결하려면 다음 명령어를 사용하여 권한을 수정한다.

권한을 수정한 후에도 오류가 지속되면, ~/.ssh 디렉토리나 키 파일의 소유권이 올바른지 확인해야 한다. 특히 루트 사용자 권한으로 파일을 생성하거나 복사한 경우, 일반 사용자 계정이 해당 파일을 소유하지 않을 수 있다. ls -la ~/.ssh 명령으로 소유자와 그룹을 확인하고, 필요시 chown 명령어를 사용하여 소유권을 현재 사용자로 변경한다[8]. 윈도우 서브시스템 for 리눅스나 맥OS의 특정 환경에서도 마운트된 드라이브나 외부 미디어에서 키를 사용할 때 유사한 권한 문제가 발생할 수 있다.

SSH 연결 시 발생하는 호스트 키 관련 오류는 클라이언트가 서버의 신원을 확인하는 과정에서 문제가 생겼을 때 나타난다. 가장 흔한 오류 메시지는 WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!이다. 이는 클라이언트에 캐시된 서버의 호스트 키 지문과 실제 연결 시도한 서버의 지문이 일치하지 않을 때 발생한다. 원인은 서버의 재설치, IP 주소 재할당, 또는 중간자 공격(Man-in-the-Middle attack)일 수 있다[9]. 사용자는 이 경고를 무시하고 연결해서는 안 되며, 먼저 서버 관리자에게 문의하여 호스트 키 변경이 정상적인 절차인지 확인해야 한다.

문제를 해결하려면 클라이언트 머신의 ~/.ssh/known_hosts 파일에서 해당 서버 항목을 제거해야 한다. 다음 명령어를 사용하여 특정 호스트의 키를 삭제할 수 있다.

```bash

ssh-keygen -R 호스트명_또는_IP주소

```

서버의 공개 키 지문을 사전에 알고 있다면, ssh-keyscan 명령어로 새 키를 미리 가져와 검증한 후 수동으로 known_hosts 파일에 추가하는 방법도 있다.

다른 일반적인 오류로 Host key verification failed가 있다. 이는 처음 연결하는 서버의 키가 known_hosts 파일에 존재하지 않아 사용자에게 확인을 요구할 때, 사용자가 'no'로 답하거나 확인 프로세스가 중단되었을 때 발생한다. 신뢰할 수 있는 서버라면 프롬프트에서 'yes'를 입력하여 키를 캐시에 저장하면 된다. 자동화 스크립트에서는 StrictHostKeyChecking 옵션을 no로 설정하여 이 확인 과정을 생략할 수 있지만, 이는 보안 위험을 증가시키므로 테스트 환경에서만 제한적으로 사용해야 한다.

SSH 연결의 보안 강도는 사용하는 암호화 키의 강도에 직접적으로 의존한다. 약한 키는 무차별 대입 공격이나 양자 컴퓨터와 같은 미래의 위협에 취약할 수 있다. 따라서 RSA, Ed25519, ECDSA 등 현대적인 키 유형 중 하나를 선택하고, 충분한 키 길이를 사용하는 것이 필수적이다.

키를 생성할 때는 예측 가능한 소스(예: 낮은 엔트로피 환경)를 사용하지 않아야 한다. 또한, 모든 서버나 서비스에 동일한 키 쌍을 재사용하는 것은 위험하다. 하나의 키가 유출되면 모든 연결이 위협받게 된다. 대신, 역할(예: 프로덕션 서버, 개인 개발, 특정 호스팅 서비스)이나 접근 수준에 따라 별도의 키 쌍을 생성하여 사용하는 것이 좋다. 이렇게 하면 유출 시 피해 범위를 국지화할 수 있다.

정기적인 SSH 키 교체는 시스템 보안을 유지하는 중요한 관행이다. 장기간 동일한 키를 사용하면 키가 노출되거나 손상될 위험이 누적되며, 이는 무단 접근으로 이어질 수 있다. 특히 키가 다수의 서버나 시스템에 등록되어 있는 경우, 하나의 키가 유출되면 광범위한 보안 침해가 발생할 수 있다. 따라서 조직의 보안 정책에 따라 6개월에서 1년, 또는 주요 인사 이동 시 등 정해진 주기에 따라 키를 교체하는 것이 권장된다.

교체 절차는 새 키 쌍을 생성하고, 기존 키를 단계적으로 대체하는 방식으로 진행된다. 먼저 ssh-keygen 명령어를 사용해 새로운 공개키와 개인키 쌍을 생성한다. 이후 새 공개키를 필요한 모든 대상 서버의 ~/.ssh/authorized_keys 파일에 추가한다. 모든 서버에 새 키가 정상적으로 등록되고 접근이 확인될 때까지는 기존 키를 삭제하지 않고 유지하여 접속 불가 상황을 방지한다.

교체 시 고려해야 할 주요 사항은 다음과 같다.

정기적인 교체는 보안 강화에 필수적이지만, 교체 주기가 지나치게 짧으면 관리 부담이 커질 수 있다. 따라서 시스템의 중요도, 규정 준수 요구사항, 그리고 실제 위협 모델을 고려하여 적절한 주기를 설정하는 것이 중요하다. 교체 후에는 관련된 모든 자동화 스크립트나 CI/CD 파이프라인 설정도 업데이트해야 한다.