SSH란 무엇인가? 작동 원리와 보안 개념 완벽 정리

SSH란 무엇인가?

SSH(secure shell)는 원격지에 있는 컴퓨터에 로그인하여 암호화된 연결을 통해 명령을 실행하기 위한 프로토콜입니다. 사용자가 입력한 내용은 원격 머신으로 전달되고, 그 출력 결과가 다시 돌아오며, 중간에서 네트워크를 감시하는 누구도 이 내용을 읽을 수 없습니다. 임대한 Linux 서버에는 화면이나 키보드가 연결되어 있지 않으므로, SSH는 해당 머신을 사용하는 유일한 방법입니다.

이 이름은 두 가지 의미를 포함합니다. SSH는 RFC 4251부터 RFC 4254까지 기술된 프로토콜 그 자체입니다. OpenSSH는 이를 구현한 프로그램이며, 거의 모든 Linux 서버와 노트북에서 실제로 실행되는 소프트웨어입니다. 누군가 "서버에 SSH로 접속한다"고 말할 때, 이는 자신의 머신에 있는 클라이언트 프로그램 ssh이 상대편의 서버 프로그램 sshd과 통신한다는 의미입니다.

SSH가 대체하고자 했던 문제

원격 로그인은 SSH보다 훨씬 오래된 기술입니다. Telnet은 23번 포트에 일반 TCP 연결을 열고 입력하는 모든 바이트를 그대로 전송했습니다. 암호화가 전혀 이루어지지 않았으며, 여기에는 비밀번호도 포함되었습니다. 네트워크 트래픽을 볼 수 있는 사람이라면 누구나 내용을 읽을 수 있었습니다. 같은 사무실 네트워크에 있는 사람이나 경로상의 라우터 운영자가 대표적인 예입니다. rlogin 계열도 같은 취약점을 가지고 있었으며, 클라이언트 머신을 이름으로 신뢰했습니다. 이는 네트워크가 주장하는 이름을 무조건 신뢰한다는 의미였습니다.

Tatu Ylönen은 1995년 헬싱키 공과대학교에서 대학 네트워크에 대한 비밀번호 스니핑 공격을 겪은 후 최초의 SSH를 작성했습니다. 이 설계는 Telnet의 유용한 부분인 터미널과 원격 셸 사이의 바이트 스트림을 유지하면서, Telnet이 해결하지 못했던 두 가지 요소인 스트림 암호화와 접속 대상 서버가 의도한 서버임을 증명하는 기능을 추가했습니다.

두 번째 요소는 간과하기 쉽지만, SSH의 절반을 차지하는 핵심입니다. 암호화만으로는 충분하지 않습니다. 중간에 있는 머신이 연결을 가로채 완벽하게 암호화한 뒤, 사용자가 보내는 모든 내용을 읽고 실제 서버로 전달할 수 있기 때문입니다. SSH는 모든 서버에 host key라는 고유한 영구 식별자를 부여하고 매 연결마다 이를 확인하는 방식으로 이러한 공격을 차단합니다.

클라이언트-서버 모델의 작동 방식

두 개의 프로그램이 존재합니다. 서버에서는 sshd가 항상 실행되며 연결을 대기합니다. 사용자 컴퓨터에서는 ssh이 연결을 생성합니다. 이들은 별도의 설정 파일을 가진 독립적인 프로그램이므로, 두 설정을 혼동하는 것이 편집 내용이 적용되지 않는 가장 흔한 원인입니다.

• 서버는 /etc/ssh/sshd_config을 읽습니다. 이 파일에서 비밀번호 로그인을 비활성화하고 수신 포트를 설정합니다.
• 클라이언트는 시스템 기본값을 위해 /etc/ssh/ssh_config를 읽고, 호스트별 개별 설정을 위해 ~/.ssh/config을 읽습니다.

Debian과 Ubuntu에서 서비스 유닛의 이름은 ssh입니다. RHEL, Rocky, Fedora에서는 sshd라고 부릅니다. 최신 Ubuntu 릴리스는 소켓 활성화 방식으로 설치되므로, 서버가 정상적으로 접속 가능한 상태임에도 systemctl status ssh이 inactive (dead) 상태를 보고할 수 있습니다. 이는 ssh.socket이 수신 대기를 담당하며 필요할 때 서비스를 시작하기 때문입니다.

클라이언트가 반드시 OpenSSH일 필요는 없습니다. Windows의 PuTTY, 스마트폰의 Termius, 편집기에 내장된 원격 지원 기능 모두 동일한 sshd와 동일한 프로토콜로 통신합니다. Windows 10과 11에는 OpenSSH 클라이언트가 포함되어 있으므로, 별도의 설치 없이 PowerShell에서 ssh you@server을 사용할 수 있습니다.

SSH는 왜 22번 포트를 사용합니까?

포트는 커널이 들어오는 연결을 어떤 리스닝 프로그램으로 전달할지 알려주는 번호이며, Linux의 포트는 모든 서비스에서 동일한 방식으로 작동합니다. SSH가 22번을 사용하는 이유는 1995년에 IANA가 해당 번호를 할당했기 때문입니다. Ylönen은 SSH가 대체하기 위해 작성된 프로토콜들 옆에 있는 빈 번호를 요청했는데, 당시 21번은 FTP, 23번은 telnet이었고 22번은 사용되지 않고 있었습니다.

22번이 기본값이기 때문에 모든 것이 이를 전제로 작동합니다. Git 리모트, 백업 스크립트, 제공업체의 제어판 모두 22번을 먼저 시도합니다. 인터넷상의 모든 자동화된 스캐너도 마찬가지입니다. 비밀번호 로그인이 활성화된 새 서버는 부팅 후 몇 분 안에 /var/log/auth.log에 다음과 같은 줄들이 쌓이기 시작합니다.

Failed password for invalid user admin from 203.0.113.55 port 43122 ssh2

이러한 트래픽은 지속적으로 발생하며, 특정 개인을 겨냥한 것이 아닙니다. sshd를 2222번 포트로 옮기면 대부분의 로그를 제거할 수 있습니다. 스캐너들은 서버를 개별적으로 분석하기보다 인터넷 전체를 22번 포트로 훑고 있기 때문입니다. 이 조치가 실제로 서버를 들여다보는 공격자에게 침입을 더 어렵게 만들지는 않습니다. 포트 변경은 단지 소음을 줄이는 용도로만 생각하십시오.

로그인하기 전에 서버가 응답하는 내용을 확인할 수 있습니다.

nc 203.0.113.10 22

Ubuntu 24.04에서는 SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13과 유사한 내용이 출력됩니다. 배너는 암호화가 이루어지기 전 평문으로 전송되는데, 이는 양측이 프로토콜 버전을 합의해야 하기 때문입니다. Ctrl+C를 눌러 연결을 종료하십시오.

연결 시 네트워크상에서 일어나는 일

아래 절차는 사용자가 프롬프트를 보기 전 ssh you@server가 수행하는 과정입니다.

1. 클라이언트는 호스트 이름을 IP 주소로 해석한 뒤, 포트 22로 TCP 연결을 엽니다.
2. 양측은 각자의 버전 배너를 평문으로 전송합니다.
3. 양측은 지원하는 알고리즘 목록(키 교환, 암호화, 메시지 인증, 압축)을 교환합니다. 이 과정도 평문으로 진행됩니다. 양측이 알고 있는 가장 강력한 옵션이 선택됩니다.
4. 키 교환이 실행됩니다. 현재 OpenSSH는 curve25519-sha256를 선호합니다. 양측은 비밀 정보를 네트워크로 직접 전송하지 않고도 동일한 공유 비밀 키를 확보하게 되므로, 전체 대화 내용을 기록한 제3자라도 나중에 이를 알아낼 수 없습니다.
5. 서버는 키 교환 결과를 호스트 개인 키로 서명합니다. 클라이언트는 파일에 저장된 호스트 공개 키를 사용하여 서명을 검증합니다. 이 단계가 중간에 있는 기기가 서버를 사칭하는 것을 방지합니다.
6. 암호화가 시작됩니다. 현재 OpenSSH의 기본 암호화 방식은 chacha20-poly1305@openssh.com입니다.
7. 이제야 클라이언트는 비밀번호나 키를 사용하여 사용자를 인증합니다. 사용자 이름과 비밀번호는 암호화된 채널 내부로 전송됩니다.
8. 클라이언트는 채널을 열고 셸을 요청합니다.

이 목록의 순서가 telnet과 결정적으로 다른 점입니다. 인증은 채널이 암호화되고 서버가 자신의 신원을 증명한 후에 이루어지므로, 비밀번호가 네트워크상에 평문으로 노출되는 순간은 존재하지 않습니다.

네트워크를 감시하는 사람은 여전히 일부 정보를 파악할 수 있습니다. 사용자의 IP 주소, 서버의 IP 주소, 포트 22, 양측의 평문 버전 배너, 그리고 모든 패킷의 타이밍과 대략적인 크기를 볼 수 있습니다. 하지만 사용자 이름, 비밀번호, 입력한 명령어, 명령어의 출력 결과는 볼 수 없습니다. 1단계의 호스트 이름 조회는 SSH의 일부가 아니며 보통 비공개로 처리되지 않으므로, 서버 이름을 해석하는 DNS 쿼리는 세션 자체가 암호화되어 있더라도 사용자가 어떤 기기에 접속하려는지 노출할 수 있습니다.

호스트 키와 최초 연결 시 지문 확인 메시지

openssh-server가 설치되면 해당 머신을 위한 호스트 키 쌍을 생성하여 /etc/ssh/ 디렉터리에 기록합니다. 예를 들어 ssh_host_ed25519_key 및 ssh_host_ed25519_key.pub 파일이 생성됩니다. 개인 키는 서버 외부로 유출되지 않습니다. 공개 키는 서버의 신원을 나타내며, 5단계에서 서명을 검증하는 기준이 됩니다.

새로운 서버에 처음 연결할 때 클라이언트는 비교할 정보가 없으므로 사용자에게 다음과 같이 묻습니다.

The authenticity of host '203.0.113.10 (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:E9nVQ5Sm2oQ3nGm5Zf1tOaU7Xh0k2p8bWc4dLrTvYxA.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

지문(fingerprint)은 호스트 공개 키를 SHA256으로 해싱한 뒤 base64로 인코딩한 값이며, 육안으로 비교할 수 있을 만큼 짧습니다. yes을 입력하면 해당 키가 사용자 머신의 ~/.ssh/known_hosts 파일에 저장됩니다. 이후 동일한 주소로 연결할 때마다 서버가 제시하는 키와 저장된 키를 비교합니다. 두 키가 일치하면 별도의 메시지 없이 바로 프롬프트로 진입합니다.

이 모델을 '최초 사용 시 신뢰(trust on first use)'라고 부르며, 이 방식의 한계를 명확히 이해해야 합니다. 최초 연결 시점은 이전에 본 적 없는 키를 수락하는 과정이므로 보호받지 못하는 유일한 순간입니다. 이 위험을 줄이려면 다른 경로를 통해 지문을 확인하고 비교해야 합니다. 대부분의 제공업체는 웹 콘솔의 부팅 출력에 지문을 표시하며, 서버 자체에서도 다음 명령으로 확인할 수 있습니다.

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

이 명령은 프롬프트에 표시되었던 것과 동일한 SHA256: 문자열을 출력합니다. 프롬프트의 [fingerprint] 옵션은 바로 이러한 확인을 위해 존재합니다. 예상되는 지문을 붙여넣으면 클라이언트는 서버가 제시한 값과 일치할 때만 연결을 계속합니다.

Debian 및 Ubuntu에서는 기본적으로 known_hosts가 해싱되어 저장되므로, 파일 내의 항목은 읽기 쉬운 호스트 이름 대신 |1|으로 시작하는 줄로 구성됩니다. 특정 호스트의 항목을 찾으려면 ssh-keygen -F 203.0.113.10을 실행하십시오.

SSH에서 호스트 키가 변경되었다고 나오는 이유는 무엇입니까?

언젠가는 다음과 같은 경고 메시지를 마주하게 됩니다.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

이 메시지는 Host key verification failed.로 끝나며 클라이언트는 연결을 거부합니다. 또한 Password authentication is disabled to avoid man-in-the-middle attacks.라는 문구도 출력되는데, 이는 알 수 없는 장비에 비밀번호를 입력하는 행위가 바로 이 검사가 방지하고자 하는 위험 요소이기 때문입니다.

메시지는 긴급 상황처럼 보이지만, 대부분의 경우 실제 위험 상황은 아닙니다. 일반적인 원인은 다음과 같습니다.

• 서버를 재구축하거나 재설치하여 sshd이 첫 부팅 시 새로운 호스트 키를 생성한 경우입니다. 이는 가장 흔한 원인입니다.
• VPS를 삭제하고 새로 생성했는데, 공급자가 이전과 동일한 IP 주소를 새 장비에 할당한 경우입니다.
• 포워딩이나 로드 밸런서를 통해 연결 중인데, 현재 다른 백엔드 장비로 연결이 전달되는 경우입니다.
• 실제로 누군가 연결을 가로채고 있는 경우입니다.

무언가를 삭제하기 전에 원인이 무엇인지 먼저 판단하십시오. 10분 전에 서버를 재설치했다면 원인은 명확합니다. 만약 본인 측에서 아무런 변경 사항이 없었다면, 즉시 중단하고 조사하십시오. 이 경고는 보안 검사가 정상적으로 작동하고 있다는 증거입니다. 확실하다면 기존의 오래된 항목을 삭제하고 다시 연결하십시오.

ssh-keygen -R 203.0.113.10

다음 연결 시 다시 지문(fingerprint) 확인 메시지가 나타나며, 이때 공급자의 콘솔에서 확인한 값과 비교할 수 있는 새로운 기회가 주어집니다.

비밀번호 로그인과 키 로그인 비교

비밀번호 인증은 이미 암호화된 채널 내부로 비밀번호를 전송하며, sshd은 일반적으로 PAM(pluggable authentication modules)을 통해 계정 데이터베이스와 이를 대조합니다. 별도의 준비 과정이 필요 없으므로, 서비스 제공자가 root 비밀번호만 설정된 상태로 새 서버를 제공할 수 있는 것입니다.

이 방식의 취약점은 암호화 자체에 있지 않습니다. 비밀번호는 짧은 비밀 정보이며, 로그인할 때마다 서버로 전송해야 하고, 22번 포트는 지치지 않는 기계들에 의해 24시간 내내 추측 공격을 당한다는 점이 문제입니다.

공개 키 인증은 다르게 작동합니다. 사용자는 자신의 컴퓨터에서 키 쌍을 생성합니다. 공개 키는 서버의 계정 내 ~/.ssh/authorized_keys에 저장됩니다. 개인 키는 사용자의 노트북에 남으며 절대 전송되지 않습니다. 로그인 시 클라이언트는 키 교환 과정에서 생성된 세션 식별자를 포함한 데이터 조각에 서명하고, 서버는 이미 보유한 공개 키를 사용하여 해당 서명을 검증합니다. 서명된 데이터는 현재 세션에만 종속되므로, 탈취된 서명은 다른 어떤 용도로도 사용할 수 없습니다.

방향을 주의하십시오. 반대로 하는 경우가 흔하며 이는 매우 위험합니다. 공개 키는 서버에 저장하고, 개인 키는 본인이 보관해야 합니다. 서버에 복사된 개인 키는 더 이상 신뢰할 수 없는 키가 됩니다.

키 로그인에도 고유한 실패 유형이 있습니다. sshd은 파일 권한이 너무 느슨하면 키를 무시하며, 서버 로그에 다음과 같이 기록합니다.

Authentication refused: bad ownership or modes for directory /home/ubuntu/.ssh

클라이언트는 항상 Permission denied (publickey)라는 메시지만 출력하는데, 이는 수십 가지의 서로 다른 원인에 대해 동일하게 표시되는 메시지입니다. 따라서 공개 키 오류를 올바르게 읽는 방법을 미리 익혀두는 것이 잠김 현상을 방지하는 데 도움이 됩니다. 키 생성, 암호(passphrase)를 통한 보호, 에이전트 로드와 같은 실무는 SSH 키 관리에서 다루며, 서버에서 고립되지 않으면서 비밀번호 로그인을 비활성화하는 방법은 VPS의 SSH 보안 강화에서 다룹니다.

SFTP, scp 및 포트 포워딩은 동일한 연결을 공유합니다

SSH 세계의 나머지 개념들을 이해하는 핵심 아이디어는 다음과 같습니다. 인증을 거쳐 암호화된 연결이 수립되면, 이 연결은 동시에 여러 개의 독립적인 채널을 운반할 수 있습니다. 셸은 이러한 여러 채널 유형 중 하나일 뿐입니다.

• 원격 셸. ssh you@server는 세션 채널을 열고 대화형 셸을 요청합니다.
• 단일 명령. ssh you@server uptime은 채널을 열고 명령 하나를 실행한 뒤, 출력을 표시하고 종료합니다.
• SFTP. 클라이언트는 sshd에 sftp 서브시스템을 시작하도록 요청하며, 파일 전송은 동일한 연결 내부에서 실행됩니다. SFTP는 SSH 위에서 동작하는 파일 전송 프로토콜이며, FTP와는 설계상 아무런 관련이 없습니다. 암호화가 추가된 FTP 프로토콜은 FTPS라고 부르며, 이는 별개의 프로토콜입니다.
• scp. 동일한 로그인을 사용하여 파일을 복사합니다. 2022년에 릴리스된 OpenSSH 9.0부터 scp는 기본적으로 내부에서 SFTP 프로토콜을 사용합니다.
• 포트 포워딩. ssh -L 8080:localhost:80 you@server은 노트북의 8080 포트를 서버의 80 포트로 연결하는 통로로 바꾸며, 이 모든 과정은 암호화된 연결 내부에서 이루어집니다. -R은 반대 방향으로 포트를 전달하며, -D 1080는 세션을 SOCKS 프록시로 전환합니다.
• Git. git@github.com:user/repo.git과 같은 원격 저장소는 셸 대신 명령 처리기를 실행하는 SSH 로그인입니다.
• rsync와 Ansible 또한 SSH 클라이언트입니다. 이들은 채널을 열고 무언가를 실행한 뒤, 그 출력을 읽어 들입니다.

이 목록에 있는 모든 항목은 동일한 포트, 동일한 호스트 키 검사, 동일한 자격 증명을 사용합니다. 이것이 바로 키 인증을 한 번 설정해 두면 즉시 그 효과를 볼 수 있는 이유입니다. 언급된 모든 도구가 해당 인증을 상속받기 때문입니다. 또한 로그인을 간소화하는 동일한 ~/.ssh/config 파일이 노트북 한 대에서 여러 리눅스 서버를 관리할 때 확장성을 제공하는 이유이기도 합니다.

SSH가 수행하지 않는 작업

• SSH는 서버를 안전하게 만들어 주지 않습니다. SSH는 문으로 향하는 경로를 보호할 뿐입니다. 문은 여전히 존재하며, 사람들은 계속해서 손잡이를 돌려보려 할 것입니다. fail2ban으로 반복적인 로그인 시도 차단하기는 이러한 시도의 양을 관리하며, 키 기반 인증만 사용하면 공격자가 추측할 대상 자체가 사라집니다.
• SSH는 사용자 본인의 기기로부터 사용자를 보호하지 않습니다. 노트북에 접근할 수 있는 사람은 누구든 사용자의 개인 키와 로드된 에이전트를 사용할 수 있습니다.
• SSH는 사용자가 SSH를 사용 중이라는 사실을 숨겨주지 않습니다. 포트 번호와 평문 버전 배너가 이를 알리기 때문입니다.
• SSH는 연결이 생성되기 전의 과정은 다루지 않습니다. 이름 조회와 어떤 주소를 신뢰할지에 대한 결정은 모두 그보다 먼저 이루어집니다.

다음 단계

현재 클라우드 제공업체 콘솔에서 새 서버를 열어둔 상태라면, 수행해야 할 작업 순서는 정해져 있습니다. 서버에 접속하여 일반 사용자를 생성하고, SSH 키를 설치한 뒤, 보안상 취약한 경로를 차단하십시오. 새 VPS에서 처음 10분 문서는 이 과정을 처음부터 끝까지 안내하며, 용어가 생소하다면 VPS의 실제 개념 문서에서 하드웨어 기반에 대한 설명을 확인할 수 있습니다. 그 후에는 키 관리와 서버 강화(hardening) 관련 문서를 순서대로 읽어보시기 바랍니다.

FAQ

SSH는 무엇의 약자입니까?

SSH는 Secure Shell의 약자입니다. 암호화된 연결을 통해 원격 컴퓨터에 로그인하고 명령을 실행하기 위한 프로토콜이며, RFC 4251에서 RFC 4254까지 정의되어 있습니다. 거의 모든 사용자가 사용하는 구현체는 OpenSSH입니다. 사용자 컴퓨터에는 ssh 클라이언트가, 원격 서버에는 sshd 서버가 설치됩니다. 이는 비밀번호를 포함한 모든 데이터를 평문으로 네트워크에 전송하던 telnet을 대체했습니다.

왜 SSH는 22번 포트를 사용합니까?

IANA는 1995년에 SSH가 대체하고자 했던 FTP(21번)와 telnet(23번) 옆인 22번 포트를 SSH에 할당했습니다. 이 번호를 강제로 사용해야 하는 것은 아닙니다. 서버에서는 /etc/ssh/sshd_config의 Port 설정을 변경하고, 클라이언트에서는 ssh -p 옵션으로 다른 포트를 지정할 수 있습니다. 22번이 기본값이기 때문에 자동화된 스캐너들이 끊임없이 접속을 시도하며, 이로 인해 새로 구축한 서버의 /var/log/auth.log에는 Failed password for invalid user 로그가 가득 차게 됩니다. 포트를 변경하면 이러한 로그 기록은 줄어들지만, 실질적인 보안 강화 효과는 없습니다.

SSH에서 호스트 키가 변경되었다는 경고가 뜨면 어떻게 해야 합니까?

무언가를 삭제하기 전에 원인을 먼저 파악하십시오. 가장 흔한 이유는 무해합니다. 서버가 재구축되어 sshd가 새로운 호스트 키를 생성했거나, 기존 IP 주소를 새로운 장비가 할당받은 경우입니다. 서버가 재구축된 사실을 알고 있다면 ssh-keygen -R <host>을 실행하여 저장된 키를 삭제하고 다시 연결하십시오. 그 후 화면에 표시되는 지문(fingerprint)을 제공업체의 콘솔에서 확인한 값과 비교하십시오. 본인 측에서 변경 사항이 없는데 경고가 발생했다면, 연결하지 말고 비밀번호를 입력하지 마십시오. OpenSSH는 바로 이러한 이유 때문에 해당 상태에서 비밀번호 인증을 거부합니다.

SFTP와 scp는 SSH와 다른 것입니까?

이들은 SSH 위에서 동작합니다. 인증이 완료되면 SSH 연결은 여러 채널을 운반할 수 있으며, 셸은 그중 하나일 뿐입니다. SFTP는 동일한 연결 위에서 sshd의 sftp 하위 시스템을 사용하는 파일 전송 프로토콜이며, scp은 OpenSSH 9.0 버전부터 내부적으로 SFTP 프로토콜을 사용합니다. 포트 포워딩과 SSH를 통한 Git 역시 동일한 연결상의 채널입니다. 이들 모두 같은 포트, 같은 호스트 키 검사, 같은 로그인 과정을 거칩니다. SFTP는 FTP에 암호화를 추가한 것이 아니라는 점에 유의하십시오. FTP에 암호화를 추가한 것은 FTPS라고 부르며 별도의 프로토콜입니다.

키 인증이 비밀번호보다 정말 더 낫습니까?

그렇습니다. 인터넷에서 접근 가능한 모든 서버에 해당합니다. 비밀번호는 로그인할 때마다 서버에 전달하는 짧은 비밀 정보이며, 22번 포트는 자동화된 클라이언트들에 의해 끊임없이 추측 공격을 받습니다. 키 쌍을 사용하면 개인 키는 절대 사용자 컴퓨터를 떠나지 않습니다. 클라이언트는 현재 세션과 연결된 데이터에 서명하고, 서버는 ~/.ssh/authorized_keys에 있는 공개 키를 사용하여 해당 서명을 검증합니다. 기록된 서명은 다른 서버를 대상으로 재사용(replay)할 수 없습니다. 개인 키는 암호(passphrase)로 보호하십시오. 암호가 없는 키 파일은 이를 복사한 누구에게나 유효한 로그인 수단이 되기 때문입니다.