SSH 키 설명
SSH 키 인증은 비밀번호 없이 서버에 로그인하는 방법입니다. 서버가 검증할 수 있는 비밀을 입력하는 대신, 사용자의 컴퓨터는 서버가 보낸 챌린지에 서명함으로써 개인 키를 보유하고 있음을 증명하고, 서버는 이미 보관 중인 공개 키로 서명을 검증합니다. 개인 키는 네트워크를 절대 건너지 않으므로 가로챌 것도, 피싱으로 낚을 것도, 추측할 것도 없습니다. 이 글에서는 키 쌍의 두 절반이 어떻게 작동하는지, 2026년에 어떤 키 종류를 선택해야 하는지, 지문이 첫 연결에서 중간자를 막는 방법, authorized_keys와 known_hosts를 깨끗하게 유지하는 방법, 그리고 키가 유출되었을 때 정확히 무엇을 해야 하는지를 설명합니다. 브라우저에서 키를 생성, 검사, 변환하려면 SSH 키 도구 모음을, 아직 사용하는 비밀번호를 확인하려면 비밀번호 유출 검사를 사용하세요.
SSH 키 인증이란 무엇인가
모든 로그인은 서버가 던지는 질문입니다. 당신이 주장하는 그 사람이 맞습니까? 비밀번호는 그 비밀 자체를 건네며 답합니다. 이것이 전체 구조의 약점입니다. 비밀은 이동하고, 도청당하고, 재생되고, 무너질 때까지 거듭 추측당합니다. SSH 키 인증은 답을 바꿉니다. 비밀을 보내는 대신, 사용자의 컴퓨터는 사용자의 컴퓨터를 절대 떠나지 않는 개인 키로 서버의 무작위 챌린지에 서명하고, 서버는 authorized_keys 파일에 저장된 공개 키로 서명을 검증합니다. 챌린지가 무작위이므로 증명은 매번 새롭습니다. 비밀이 통신선에 절대 나타나지 않으므로 도청자는 재사용할 수 있는 것을 아무것도 배우지 못합니다. 그리고 애초에 비밀번호가 관여하지 않으므로 추측할 비밀번호도 없습니다.
이 아이디어는 현대 인터넷보다 오래되었으며, 공개 키 암호는 1970년대로 거슬러 올라갑니다. 하지만 SSH는 이를 서버에 도달하는 일상적인 방법으로 만들었고, 프로토콜은 그 이후로 이를 이어왔습니다. ssh user@server를 실행하면 클라이언트와 서버는 세션에 합의하고, 서버는 사용자의 계정에 연결된 챌린지를 제시하며, 사용자의 SSH 에이전트는 개인 키로 서명합니다. 보통은 암호로 키를 한 번 잠금 해제한 뒤입니다. 서명이 검증되면 로그인됩니다. 이 교환은 서버도 알고 있는 공유 비밀에 전혀 의존하지 않으므로, 서버가 침해되더라도 사용자의 자격 증명이 노출되지 않습니다. 서버가 보유한 것은 공개 키뿐이며, 공개 키는 로그인에 무용하기 때문입니다. 이 비대칭성, 즉 서버는 검증할 수 있지만 사칭할 수는 없다는 점이 키의 보안 논거 전부이며, 개인 절반의 통제력을 잃는 것이 유일하게 중요한 실패인 이유이기도 합니다.
공개 키와 개인 키
키 쌍은 정반대의 규칙을 가진 두 절반이며, 대부분의 SSH 실수는 이를 동일하게 취급하는 데서 옵니다. 공개 키는 모든 곳에 복사하기 위한 것입니다. 사용하는 모든 서버의 authorized_keys, Git 호스팅 계정, SSH 키를 허용하는 모든 서비스에 붙여넣으세요. 공개 저장소에 게시하거나, 슬라이드에 인쇄하거나, 관리자에게 이메일로 보낼 수 있습니다. 이를 통해 누구든 할 수 있는 일은 서명을 검증하는 것뿐이기 때문입니다. 사용자의 공개 키를 안다고 해서 공격자가 로그인할 수단을 얻는 것은 아닙니다. 집 번호를 안다고 해서 누구든 현관 열쇠를 얻는 것이 아닌 것과 같습니다. 공개 절반은 자물쇠이지 열쇠가 아니며, 자물쇠는 보이도록 만들어졌습니다.
개인 키는 열쇠 그 자체이며, 그 규칙은 정확히 반대입니다. 사용자의 컴퓨터를 절대 떠나지 않고, 사용자만 읽을 수 있으며, 채팅, 티켓, 이메일, 포럼 게시물, 공유 문서에 절대 붙여넣어서는 안 됩니다. 안전한지 물어보기 위해서라도 안 됩니다. 이를 가진 사람은 해당 공개 키를 신뢰하는 모든 서버에 사용자로 로그인할 수 있으며, 설정하지 않았다면 비밀번호 프롬프트도 두 번째 요소도 중간에 없습니다. 디스크에서는 ~/.ssh에 살며 파일 권한, 즉 chmod 600(소유자만 읽기·쓰기 가능)으로 보호되고, 이상적으로는 암호로도 보호됩니다. 암호는 파일을 암호화하므로, 도난당한 복사본도 이를 잠금 해제하는 말이 없으면 여전히 무용합니다. 암호는 키의 일부가 아닙니다. 열쇠가 들어 있는 상자의 자물쇠입니다. 상자를 잃으면 자물쇠가 도둑과 사용자의 서버 사이에 있는 유일한 것이 되며, 그래서 암호가 없는 개인 키는 사용자가 완전히 통제하는 컴퓨터를 절대 떠나서는 안 됩니다.
Ed25519 대 ECDSA 대 RSA: 2026년에 무엇을 선택할 것인가
2026년의 기본 답은 Ed25519이며, 이 사이트가 생성하는 기본값이기도 합니다. Ed25519는 256비트 타원 곡선 키입니다. 1초의 일부 만에 생성되고, 서명이 빠르며, 공개 키가 짧은 한 줄에 들어갑니다. 2014년부터 OpenSSH와 모든 최신 서버 및 클라이언트가 지원해 왔으며, 그 보안은 의심스러운 상수가 없는 공개적으로 설계된 곡선에 기반합니다. 환경의 무언가가 손을 묶지 않는 한, 새 키에 다른 것을 선택할 실질적인 이유는 없습니다. 이 글에서 하나의 권장 사항만 가져간다면 이것입니다. Ed25519를 생성하고, 암호를 설정한 뒤, 계속 나아가세요.
다른 종류는 예외를 위해 존재합니다. NIST P-256 또는 P-384 곡선상의 ECDSA는 정책이 NIST 곡선을 요구하는 경우의 올바른 선택입니다. 일부 규제 환경과 오래된 하드웨어 토큰이 이를 지정하며, 브라우저나 기기가 Ed25519를 생성할 수 없을 때 확실한 대안이기도 합니다. RSA는 여전히 범용 대안입니다. RSA 2048이 사용할 만한 최소값이며, RSA 3072 또는 4096은 상대방이 타원 곡선을 전혀 사용할 수 없을 때의 선택으로, 오늘날 이는 주로 매우 오래된 시스템과 일부 임베디드 기기를 의미합니다. RSA 2048 미만의 모든 것, 즉 RSA 1024, DSA, ssh-dss는 구식이며 폐기해야 합니다. SSH 키 도구 모음이 이를 취약한 것으로 표시하는 것은 바로 그 때문입니다. 하지만 키 크기가 전부는 아닙니다. 더 이상 소유하지 않은 노트북에 복사된 4096비트 RSA 키는 제대로 보관된 256비트 Ed25519 키보다 나쁩니다. SSH 키의 실패 모드는 거의 결코 수학이 아니기 때문입니다. 파일입니다.
지문과 첫 연결
서버에 처음 연결하면 SSH는 무작위 문자열처럼 보이는 것을 표시하고 이를 신뢰할지 묻습니다. 256 SHA256:M8zvXkwyrGfPUmaHSSdA1aFQkH8AVSRycOxaZHru7dQ. 이 문자열은 서버 호스트 키의 지문, 즉 서버 공개 키의 해시이며, 사용자와 중간자 사이에 있는 유일한 것입니다. 지문이 관리자가 게시한 것, 또는 별도 채널로 확인한 것과 일치하면, 응답하는 컴퓨터는 정말로 사용자가 도달하려던 서버입니다. 일치하지 않으면 멈추세요. 누군가 연결을 가로채고 있거나, 서버가 새 키로 재구축되었을 수 있으며, 어느 쪽이든 안전한 행동은 yes를 입력하기 전에 확인하는 것입니다. 이 프롬프트는 SSH가 가장 중요한 일을 하고 있는 순간이며, 곤경에 빠지는 사람들은 읽지 않고 yes를 입력하도록 스스로 훈련한 사람들입니다.
지문은 연결하기 전에 ssh-keygen -lf로 확인할 수 있습니다. 이는 키마다 한 줄을 출력합니다. 비트 크기, 지문, 주석, 대괄호 안의 키 종류입니다. 예를 들어 256 SHA256:… [email protected] (ED25519)와 같습니다. SSH 키 도구 모음은 지문을 정확히 같은 형식으로 출력하므로, 브라우저에서 보는 값을 서버가 표시하는 것과 문자 단위로 비교할 수 있습니다. 호스트 키를 한 번 수락하면 SSH는 이를 ~/.ssh/known_hosts에 저장하고, 바뀌는 경우 크게 경고하며 연결을 거부합니다. 이 경고는 플래그로 우회해야 할 성가심이 아닙니다. 울리고 있는 경보입니다. 유일한 일상적인 예외는 정당하게 재구축된 서버이며, 이 경우 관리자는 새 지문을 미리 게시했어야 하고, 사용자는 다시 연결하기 전에 ssh-keygen -R hostname으로 이전 항목을 제거합니다.
authorized_keys 위생과 known_hosts
서버의 authorized_keys 파일의 각 줄은 하나의 문이며, 문은 그 문이 필요했던 사람이 떠난 뒤에도 오랫동안 열려 있습니다. 외주 업체 직원의 노트북, 지속적 통합 작업, 이후 삭제된 컴퓨터에서 생성된 키, 2년 전 팀을 옮긴 동료. 각각은 지금도 작동하는 줄이며, 각각은 사용자가 더 이상 지켜보지 않는 자격 증명입니다. 감사는 간단하며 몇 달에 한 번씩 할 가치가 있습니다. 파일을 복사하여 SSH 키 도구 모음의 「검사」 탭에 붙여넣고 돌아오는 것을 보세요. 중복, 즉 같은 공개 키가 두 번 있는 것은 누군가 확인하는 대신 키를 다시 붙여넣었다는 뜻이며, 한 줄로 합쳐야 합니다. 취약한 항목, 즉 2048 미만의 RSA, DSA, ssh-dss는 제거하고 교체해야 합니다. 그리고 주석에 언급된 사람, 컴퓨터, 목적을 더 이상 알아보지 못하는 줄은, 소유자가 나타날 때까지 닫아야 할 문으로 취급해야 합니다.
known_hosts도 반대편에서 같은 주의를 받을 만합니다. 연결한 모든 서버의 호스트 키를 기록하며, SSH는 이를 기준으로 모든 새 연결을 확인합니다. 일부 항목은 해시되어 있습니다. |1| 뒤에 base64가 오는 형태로, 호스트 이름을 숨깁니다. 이는 분실되거나 검사받을 수 있는 노트북을 위한 개인정보 보호 기능입니다. SSH 키 도구 모음은 이러한 항목을 읽을 수 있는 것처럼 가장하는 대신 해시된 것으로 보고합니다. 해시된 항목은 게시된 지문과 대조하여 검증할 수 없고, 이미 수락된 것으로 신뢰할 수밖에 없기 때문입니다. 파일 자체도 증거입니다. 더 이상 사용하지 않는 서버로 가득한 known_hosts는 사용자의 자격 증명이 어디에 있었는지의 지도이며, 정리하는 데 아무것도 들지 않습니다. 두 파일을 합치면 양방향 SSH 신뢰의 완전한 기록이 됩니다. 누가 사용자로 로그인할 수 있는지, 그리고 어떤 컴퓨터를 그 자체로 신뢰하는지. 둘 다 아무도 보지 않으면 조용히 썩어갑니다.
키가 유출되었을 때 — 그리고 암호에 대한 참고
유출된 키는 먼저 조사하고 나중에 행동할 수수께끼가 아닙니다. 교체해야 할 키이며, 작업 순서는 짧습니다. 새 키 쌍을 생성하세요. 이전 공개 키를 모든 서버와 모든 서비스의 authorized_keys에서 제거하세요. 사용자의 서버, Git 호스팅, 배포 파이프라인, 키가 설치된 모든 곳입니다. 그런 다음 이전 키가 무엇에 도달할 수 있었는지 확인하고, 자리에 맞지 않는 것이 있는지 찾으세요. 사용자가 추가하지 않은 authorized_keys의 새 줄, 사용자가 일하지 않았던 시간대의 로그인, 낯선 프로세스입니다. 무언가를 발견하면 이를 놀라움이 아니라 침해로 취급하고, 거기서부터 조사하세요. 하지 말아야 할 일은 이전 개인 키를 자신의 노트북에서 삭제하고 일이 끝났다고 여기는 것입니다. 자신의 복사본을 삭제한다고 해서 유출된 복사본에 아무런 효과가 없으며, authorized_keys에 여전히 남아 있는 공개 키는 지금도 작동하는 문입니다.
암호는 이 체크리스트를 바꾸지 않지만, 이를 실행하는 긴급도는 바꿉니다. 파일로 유출된 암호 보호 키는 여전히 문제입니다. 공격자는 오프라인에서 기계 속도로 암호를 추측하려 할 수 있습니다. 하지만 강력한 암호는 추측이 성공하기 전에 교체할 시간을 벌어줍니다. 암호화되지 않은 키는 시간을 전혀 벌어주지 않으며, 그래서 이 사이트는 생성기가 무엇을 만들어내는지에 대해 솔직합니다. 버전 1은 암호화되지 않은 키를 생성하며 암호 옵션이 없습니다. 암호화된 개인 키를 위한 OpenSSH의 bcrypt KDF는 버전 2 범위이기 때문입니다. 여기서 키를 생성했다면 chmod 600으로 파일을 보호하고, 자신의 컴퓨터에서 ssh-keygen -p로 암호를 추가하세요. 10초면 되며, 파일을 제자리에서 변환하고, 이 글 전체에서 가장 가치 있는 습관입니다. 키를 생성하고, 암호를 설정하고, 공개 절반만 설치하고, 1년에 두 번 파일을 감사하고, 신뢰하기 전에 모든 지문을 확인하세요. 그것이 규율의 전부이며, 색인 카드에 들어갑니다.