공개키 암호화 방식

SSH에서 공개키 암호화를 이용한 인증 프로세스는 클라이언트가 서버에 자신의 신원을 증명하는 방법이다. 이 과정은 비밀번호를 입력하지 않고도 안전한 접속을 가능하게 한다. 핵심은 클라이언트가 개인키를 소유하고 있다는 사실을 암호학적으로 증명하는 데 있다.

인증 프로세스는 다음과 같은 단계로 진행된다. 먼저, 클라이언트는 연결을 시도할 때 서버에 자신의 공개키를 전송한다. 서버는 이 공개키가 미리 등록된 사용자의 ~/.ssh/authorized_keys 파일에 존재하는지 확인한다. 공개키가 등록되어 있으면, 서버는 클라이언트에게 임의의 메시지(챌린지)를 생성하여 전송한다. 이 메시지는 클라이언트의 개인키로만 서명할 수 있다.

클라이언트는 수신한 챌린지 메시지를 자신이 보관하고 있는 개인키로 서명한다. 이렇게 생성된 디지털 서명을 서버로 되돌려 보낸다. 서버는 처음에 받은 공개키를 이용해 이 서명을 검증한다. 공개키로 서명 검증에 성공하면, 클라이언트가 해당 개인키의 소유자임이 증명되고 인증이 완료된다. 개인키는 절대 네트워크를 통해 전송되지 않는다.

이 프로세스의 보안성은 개인키의 비밀 유지에 달려 있다. 서버는 공개키만을 저장하며, 이는 외부에 공개되어도 안전하다. 인증 성공 후, 양측은 보통 대칭키 암호를 사용한 보안 채널을 수립하여 이후의 모든 통신을 암호화한다.

SSH 연결에서 대칭키 암호를 사용한 실제 데이터 통신을 시작하기 전, 클라이언트와 서버는 안전하게 세션 키를 협상해야 합니다. 이 과정을 키 교환 또는 키 교환 알고리즘이라고 합니다. 공개키 암호화 방식은 이 세션 키 교환을 안전하게 수행하는 데 핵심적인 역할을 합니다.

주로 사용되는 키 교환 알고리즘은 디피-헬만 키 교환과 그 변종들(예: ECDH)입니다. 이 프로토콜은 두 당사자가 공개 채널을 통해 정보를 교환하여 공통의 비밀값을 도출할 수 있게 합니다. 구체적인 과정은 다음과 같습니다.

1. 연결 초기화 시, 클라이언트와 서버는 지원하는 키 교환 알고리즘 목록을 교환하고 공통으로 지원하는 하나를 선택합니다.

2. 서버는 자신의 공개키를 포함한 서버 공개키 호스트 키를 클라이언트에 보냅니다. 클라이언트는 이 키를 통해 서버의 신원을 확인합니다[1].

3. 선택된 키 교환 알고리즘에 따라, 클라이언트와 서버는 각각 임시 키 쌍을 생성하고 공개키 부분만 상대방에게 전송합니다.

4. 각자는 자신의 개인키와 상대방의 공개키를 사용하여 동일한 공유 비밀을 독립적으로 계산합니다. 이 계산된 값은 제3자가 도청하더라도 알 수 없습니다.

5. 이 공유 비밀을 기반으로, 양측은 이후 통신에 사용할 실제 대칭키 암호의 세션 키를 생성합니다.

이렇게 생성된 세션 키는 연결 기간 동안 데이터의 기밀성과 무결성을 보호하는 데 사용됩니다. 이 교환 방식의 주요 이점은 사전에 비밀키를 공유할 필요 없이 안전한 채널을 수립할 수 있다는 점입니다. 또한, 각 SSH 세션마다 고유한 세션 키가 생성되므로, 하나의 세션 키가 유출되더라도 다른 세션은 안전하게 보호됩니다.

SSH 키 쌍을 생성할 때는 다양한 암호화 알고리즘 중 하나를 선택할 수 있다. 각 알고리즘은 키 길이, 성능, 보안 강도 측면에서 차이를 보인다. 역사적으로 RSA 알고리즘이 가장 널리 사용되었지만, 최근에는 Ed25519와 같은 더 현대적인 타원곡선 암호 기반 알고리즘의 채용이 권장된다.

주요 알고리즘과 그 특징은 다음과 같다.

RSA 키는 ssh-keygen -t rsa -b 4096 명령으로 생성할 수 있으며, 2048비트는 현재 최소한의 길이로 간주된다. Ed25519 키는 ssh-keygen -t ed25519 명령으로 생성한다. ECDSA의 경우 ssh-keygen -t ecdsa -b 256과 같이 생성하며, 키 길이는 256, 384, 521비트 중 선택할 수 있다.

알고리즘 선택은 보안 요구사항과 호환성에 따라 결정된다. 새로운 시스템에서는 Ed25519를 우선적으로 고려하는 것이 좋다. 이는 동일한 보안 수준에서 더 나은 성능을 제공하며, 키 크기도 작기 때문이다. 그러나 오래된 클라이언트나 서버 소프트웨어는 Ed25519를 지원하지 않을 수 있어, 이 경우 RSA 3072비트 이상을 사용하는 것이 대안이 될 수 있다.

SSH 서버에 사용자를 인증하기 위해서는 클라이언트의 공개키를 서버에 등록해야 한다. 이 과정을 '공개키 배포'라고 하며, 등록된 키는 일반적으로 서버의 사용자 홈 디렉터리 내 .ssh/authorized_keys 파일에 저장된다. 이 파일은 해당 사용자 계정으로의 공개키 인증을 허용할 공개키들의 목록을 담고 있다.

authorized_keys 파일의 각 줄은 하나의 공개키를 나타낸다. 한 줄은 키 유형, 공개키 자체, 그리고 선택적으로 주석으로 구성된다. 서버는 클라이언트가 연결을 시도할 때, 클라이언트가 제시하는 공개키가 이 파일의 어느 한 줄과 정확히 일치하는지 확인한다. 일치하는 키가 있으면, 해당 클라이언트는 서버에 제시한 개인키를 소유하고 있다는 것을 암호학적으로 증명해야 하는 다음 단계로 진행한다.

공개키를 배포하는 일반적인 방법은 ssh-copy-id 명령어를 사용하는 것이다. 이 명령어는 로컬에 있는 공개키 파일(예: ~/.ssh/id_rsa.pub)을 지정된 서버와 사용자 계정의 authorized_keys 파일 끝에 자동으로 추가한다. 명령어 형식은 ssh-copy-id user@hostname이다. 수동으로 배포하려면 클라이언트의 공개키 내용을 복사하여 서버의 ~/.ssh/authorized_keys 파일 끝에 붙여넣으면 된다.

authorized_keys 파일과 상위 .ssh 디렉터리의 권한 설정은 보안상 매우 중요하다. 서버는 과도하게 개방된 권한을 가진 이 파일을 신뢰하지 않는다. 일반적으로 다음과 같은 권한이 요구된다.

권한이 올바르게 설정되지 않으면 서버가 공개키 인증을 거부하고 대신 비밀번호 인증을 요구할 수 있다. 또한, 이 파일을 관리함으로써 서버 관리자는 특정 키에 대해 원격 명령 제한이나 에이전트 포워딩 제한과 같은 고급 옵션을 설정할 수 있다[3].

SSH 개인키는 접속하려는 시스템에 대한 모든 권한을 부여하는 매우 민감한 정보이다. 따라서 이를 안전하게 보관하고 관리하는 관행은 시스템 보안의 핵심이다.

가장 기본적인 원칙은 개인키를 절대 타인과 공유하거나 네트워크를 통해 전송하지 않는 것이다. 개인키는 생성된 클라이언트 시스템에만 보관해야 한다. 키 파일의 파일 시스템 권한은 반드시 제한적으로 설정되어야 한다. 일반적으로, 사용자 본인만 읽을 수 있도록 600 (소유자 읽기/쓰기) 권한으로 설정하는 것이 표준 관행이다. 권한이 너무 개방적이면(예: 644), SSH 클라이언트가 보안 위험을 이유로 키 사용을 거부할 수 있다[4].

개인키의 보안성을 추가로 강화하기 위해 패스프레이즈를 사용하는 것이 강력히 권장된다. 패스프레이즈는 개인키 파일 자체를 대칭키 암호로 암호화하여, 키를 사용할 때마다 올바른 구문을 입력해야만 복호화하도록 한다. 이는 개인키 파일이 유출되더라도 패스프레이즈를 모르면 키를 사용할 수 없게 하는 중요한 보안 계층을 추가한다. 패스프레이즈 관리는 SSH 에이전트를 활용하여 편의성을 높일 수 있다. 에이전트는 메모리에 복호화된 키를 일시적으로 보관하여 세션 동안 반복적인 패스프레이즈 입력을 줄여준다.

또한, 개인키의 백업은 신중하게 수행해야 한다. 백업이 필요하다면, 암호화된 저장 매체나 완전히 오프라인인 안전한 장소에 보관한다. 마지막으로, 정기적인 키 교체 정책을 수립하는 것이 좋다. 장기간 동일한 키를 사용하면 노출 위험이 누적될 수 있으므로, 일정 기간이 지나면 새로운 키 쌍을 생성하고 서버의 authorized_keys 파일에서 이전 공개키를 제거해야 한다.

클라이언트 측에서 공개키 암호화 방식을 이용한 SSH 인증을 설정하려면, 먼저 키 쌍을 생성하고 생성된 공개키를 원격 서버에 등록해야 한다. 주요 단계는 다음과 같다.

첫 번째 단계는 ssh-keygen 명령어를 사용하여 키 쌍을 생성하는 것이다. 이 명령을 실행하면 키 유형(예: RSA, Ed25519)과 키 길이, 저장 경로, 그리고 선택적으로 패스프레이즈를 설정할 수 있다. 일반적인 Ed25519 키 생성 명령은 ssh-keygen -t ed25519이다. 명령을 실행하면 기본적으로 사용자의 ~/.ssh/ 디렉토리에 id_ed25519(개인키)와 id_ed25519.pub(공개키) 파일이 생성된다.

생성된 공개키를 원격 서버에 등록하는 방법은 주로 ssh-copy-id 명령어를 사용한다. 이 명령은 공개키를 지정된 서버의 ~/.ssh/authorized_keys 파일에 자동으로 추가한다. 예를 들어, ssh-copy-id user@remote_server 명령을 실행하면, 해당 서버의 사용자 계정 authorized_keys 파일에 클라이언트의 공개키가 추가된다. ssh-copy-id 도구를 사용할 수 없는 환경에서는, 공개키 내용을 수동으로 복사하여 서버 측에서 동일한 파일에 붙여넣는 방식으로 등록할 수 있다. 설정이 완료되면, 이후 접속 시 비밀번호 대신 개인키(및 설정한 패스프레이즈)를 사용하여 인증하게 된다.

서버 측에서 공개키 인증을 활성화하려면, 클라이언트의 공개키를 신뢰할 수 있는 키 목록에 등록해야 한다. 이 작업은 일반적으로 대상 사용자의 홈 디렉토리 내 ~/.ssh/authorized_keys 파일을 수정하여 수행한다. 시스템 관리자는 /etc/ssh/sshd_config 구성 파일을 편집하여 비밀번호 인증을 비활성화하고 공개키 인증만 허용하도록 강제할 수 있다.

authorized_keys 파일에 공개키를 등록하는 기본 절차는 다음과 같다.

1. 클라이언트에서 생성된 공개키(예: id_ed25519.pub 파일의 내용)를 복사한다.

2. 서버의 대상 사용자 계정으로 로그인한다.

3. ~/.ssh 디렉토리가 존재하는지 확인하고, 없다면 적절한 권한(700)으로 생성한다.

4. ~/.ssh/authorized_keys 파일을 열어 복사한 공개키 내용을 새로운 줄에 붙여넣고 저장한다. 이 파일의 권한은 반드시 600으로 설정해야 한다[5].

주요 sshd_config 설정 옵션은 아래와 같다.

설정 변경 후에는 SSH 데몬을 재시작하여 변경사항을 적용해야 한다(예: systemctl restart sshd). 새로운 공개키 인증 방식으로 연결을 시도하기 전에, 기존의 연결 세션을 종료하지 않고 다른 터미널 창을 열어 서버에 접속된 상태를 유지하는 것이 좋다. 이는 설정 오류로 인한 접속 차단 시 문제를 해결할 수 있는 백도어 역할을 한다.

SSH 연결의 장기적 보안은 사용하는 암호화 키의 강도와 암호 알고리즘의 선택에 직접적으로 의존한다. 키 강도는 일반적으로 키의 길이(비트 수)로 표현되며, 이는 무차별 대입 공격에 대한 저항력을 결정한다. 역사적으로 RSA 알고리즘이 가장 널리 사용되었으나, 최신 시스템에서는 타원곡선 암호 기반 알고리즘인 ECDSA나 Ed25519가 더 효율적이고 강력한 옵션으로 권장된다. 알고리즘 선택은 호환성과 보안 수준 사이의 균형을 고려해야 한다.

다음 표는 일반적인 SSH 키 알고리즘을 비교한 것이다.

키 강도를 선택할 때는 보호하려는 데이터의 가치와 예상되는 위협 수준을 고려해야 한다. 현재 기준으로 2048비트 RSA 키는 단기적으로는 안전할 수 있으나, 장기적인 보안을 위해서는 3072비트 또는 4096비트를 사용하는 것이 좋다. Ed25519는 256비트 키로도 매우 높은 보안 수준을 제공하며, 성능 면에서도 우수하다. 중요한 것은 오래되고 취약한 것으로 알려진 알고리즘(예: 1024비트 RSA 또는 DSA)을 사용하지 않는 것이다.

서버 측에서는 sshd_config 파일을 통해 허용할 공개키 인증 알고리즘을 제한할 수 있다. PubkeyAcceptedKeyTypes 지시어를 사용하여 강력한 알고리즘(예: ssh-ed25519,ecdsa-sha2-nistp256,rsa-sha2-512)만 허용하고, 오래된 알고리즘은 명시적으로 제외하는 것이 모범 사례이다. 이렇게 하면 클라이언트가 약한 키를 사용하여 연결하는 것을 방지할 수 있다. 알고리즘 지원 현황은 SSH 클라이언트와 서버의 버전에 따라 달라질 수 있으므로, 호환성을 테스트하는 것이 필요하다.

패스프레이즈는 개인키 파일을 암호화하는 데 사용되는 추가적인 암호 구문이다. 이는 개인키 파일이 유출되더라도 패스프레이즈를 모르면 키를 사용할 수 없게 함으로써 보안을 강화하는 역할을 한다. 키 생성 시 ssh-keygen 명령어를 실행하면 패스프레이즈를 설정할 수 있으며, 이후 해당 키를 사용해 연결할 때마다 패스프레이즈를 입력해야 한다.

패스프레이즈 사용의 주요 장점은 방어 심층화를 제공한다는 점이다. 예를 들어, 개인키가 저장된 노트북을 분실하거나 백업 미디어가 도난당한 경우, 공격자는 암호화된 개인키 파일을 획득하더라도 실제로 사용할 수 없다. 또한, 시스템 메모리에 상주하는 SSH 에이전트 같은 도구를 사용하면 연결 세션 동안 패스프레이즈를 한 번만 입력하면 되므로 사용 편의성과 보안을 동시에 확보할 수 있다.

그러나 패스프레이즈 사용은 자동화 스크립트나 무인 배포 프로세스에서는 문제가 될 수 있다. 이러한 경우에는 패스프레이즈 없이 키를 생성하거나, SSH 에이전트를 통해 미리 키를 로드해 두는 방법을 고려해야 한다. 패스프레이즈는 충분히 길고 복잡해야 하며, 다른 서비스의 암호와 동일하게 재사용해서는 안 된다. 키의 보안 수준은 결국 가장 약한 요소에 의해 결정되므로, 강력한 암호화 알고리즘으로 생성된 키라도 약한 패스프레이즈로 인해 전체 보안이 무너질 수 있다.

SSH 클라이언트가 공개키 인증을 사용하여 서버에 연결할 때 발생하는 일반적인 오류와 그 해결 방법은 다음과 같다.

가장 흔한 오류는 "Permission denied (publickey)"이다. 이는 서버가 제시된 공개키를 인증에 사용할 수 없음을 의미한다. 주요 원인과 해결책은 다음과 같다.

* 잘못된 공개키 등록: 클라이언트의 공개키가 서버의 ~/.ssh/authorized_keys 파일에 정확히 등록되지 않았다. 공개키를 다시 복사하거나 ssh-copy-id 명령어를 사용하여 등록을 확인한다.

* 파일 권한 문제: 서버 측의 ~/.ssh 디렉터리나 authorized_keys 파일의 권한이 너무 개방적이다. 일반적으로 ~/.ssh 디렉터리는 700 (drwx------), authorized_keys 파일은 600 (-rw-------) 권한이어야 한다. chmod 명령으로 수정한다.

* 잘못된 개인키 지정: 클라이언트가 기본 경로(~/.ssh/id_rsa, ~/.ssh/id_ed25519 등)가 아닌 다른 키를 사용할 때, -i 옵션으로 올바른 개인키 파일 경로를 명시적으로 지정하지 않았다. ssh -i /경로/개인키 사용자@호스트 형식으로 연결을 시도한다.

"Agent admitted failure to sign using the key" 오류는 SSH 에이전트가 개인키에 대한 접근이나 사용에 실패했을 때 발생한다. ssh-add 명령을 실행하여 키를 에이전트에 명시적으로 추가하면 해결될 수 있다. 또한 "Too many authentication failures" 오류는 클라이언트가 제한 횟수 내에 올바른 키를 제시하지 못했을 때 발생한다. 이 경우 -o PubkeyAuthentication=no 옵션을 일시적으로 사용하여 공개키 인증 시도를 비활성화하거나, ssh -i 옵션으로 정확한 키 하나만 지정하여 연결을 시도할 수 있다.

연결 문제의 근본 원인을 파악하려면 클라이언트와 서버 양쪽의 로그를 확인하는 것이 유용하다. 클라이언트는 -v (verbose) 옵션을 추가하여 디버그 메시지를 출력하게 할 수 있다(예: ssh -v 사용자@호스트). 서버 측 로그(일반적으로 /var/log/auth.log 또는 /var/log/secure)를 검토하면 인증 실패에 대한 상세한 시스템 기록을 확인할 수 있다.

SSH 공개키 암호화 방식을 사용할 때 발생하는 권한 문제는 주로 파일 및 디렉터리의 소유권과 접근 권한 설정이 부적절하여 발생합니다. 대부분의 SSH 서버, 특히 OpenSSH는 보안상의 이유로 과도하게 개방된 권한을 가진 파일을 신뢰하지 않습니다.

가장 흔한 문제는 사용자의 홈 디렉터리(~), .ssh 디렉터리, 그리고 그 내부의 authorized_keys 파일에 대한 권한 설정입니다. 서버는 일반적으로 다음의 엄격한 권한을 요구합니다.

권한 문제가 발생하면 서버는 보안 로그(예: /var/log/auth.log 또는 /var/log/secure)에 "Authentication refused: bad ownership or modes"와 같은 메시지를 기록합니다. 이 문제를 해결하기 위해선 chmod와 chown 명령어를 사용하여 올바른 소유권과 권한을 재설정해야 합니다. 예를 들어, authorized_keys 파일의 권한을 수정하려면 chmod 600 ~/.ssh/authorized_keys 명령을 실행합니다.

또 다른 권한 문제는 셸이 로그인 시 사용자의 .ssh 디렉터리나 관련 파일을 읽을 수 없는 경우 발생할 수 있습니다. 이는 디렉터리 경로 상의 모든 상위 디렉터리에 대해 다른 사용자(others)에게 실행(x) 권한이 있어야 하기 때문입니다. 예를 들어, 홈 디렉터리의 권한이 750이라면, 해당 사용자로의 SSH 접근은 정상 작동하지만, 권한이 770으로 설정되어 다른 사용자에게 쓰기 권한이 주어지면 보안 검사에 실패할 수 있습니다.