비밀번호 대신 키 쌍으로 증명해
SSH 공개 키 인증은 개인 키를 클라이언트에 보관하고 공개 키를 서버 계정에 등록해. 서버는 개인 키 자체를 받지 않고도 클라이언트가 해당 키를 사용할 수 있다는 서명을 검증해. 비밀번호를 반복 전송하지 않고 자동화하기 좋지만, 개인 키와 서버의 등록 권한을 제대로 관리해야 안전해.
현대 환경에서는 Ed25519부터 검토해
ssh-keygen -t ed25519 -C 'me@laptop'Ed25519는 키가 작고 빠르며 현대 OpenSSH에서 널리 지원돼. 호환되지 않는 오래된 장비가 있다면 해당 장비의 지원 범위를 확인한 뒤 RSA 4096 같은 대안을 선택해. 기본 저장 경로를 사용할 때도 기존 키를 덮지 않는지 보고, 분실 시 무단 사용 시간을 줄이도록 충분한 passphrase를 설정해.
공개 키만 서버에 등록해
ssh-copy-id user@server
# 또는 공개 키 한 줄을 서버의 ~/.ssh/authorized_keys에 추가.pub 파일은 배포할 수 있지만 개인 키 파일은 서버나 다른 사용자에게 보내지 마. 각 기기가 자기 키 쌍을 갖게 하면 분실한 기기의 공개 키만 서버에서 제거할 수 있고, 접속 기록도 키별로 추적하기 쉬워.
ssh-agent는 반복 입력을 줄여
agent는 잠금 해제한 키를 이용해 서명 요청을 대신 처리하므로 ssh, scp와 Git이 매번 passphrase를 묻지 않게 해. macOS에서는 Keychain 연동 옵션을 사용할 수 있지만, agent에 키가 올라가 있다는 사실이 그 키를 사용하는 모든 프로세스를 자동으로 신뢰해도 된다는 뜻은 아니야. agent forwarding은 원격 호스트가 서명 요청을 보낼 수 있는 경계를 넓히므로 꼭 필요한 호스트에만 제한해.
파일 권한이 너무 넓으면 OpenSSH가 거부해
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
chmod 600 ~/.ssh/config권한 숫자를 기계적으로 적용하기 전에 소유자와 실제 경로를 확인해. 개인 키를 여러 위치에 복사하기보다 사용 경로를 줄이고, 백업은 암호화된 자격 증명 관리 정책 안에서 다뤄.
키 수명과 권한을 기기별로 관리해
노트북, 데스크톱과 자동화 서비스가 한 개인 키를 공유하면 어느 복제본이 유출됐는지 알기 어렵고 하나만 폐기할 수도 없어. 키마다 용도와 기기 이름을 주석으로 남기고 서버에서는 필요한 계정과 명령 범위만 허용해. 사용하지 않는 키는 정기적으로 제거하고, 접근을 끊은 뒤 실제 인증이 거부되는지 확인해.
호스트 키를 확인해야 연결 대상도 믿을 수 있어
사용자 키는 서버에 나를 증명하고, 호스트 키는 접속한 서버가 내가 의도한 서버인지 증명해. 첫 연결의 지문을 별도 신뢰 경로로 확인하지 않고 승인하면 암호화된 채 공격자에게 연결될 수 있어. 호스트 키 변경 경고가 뜨면 known_hosts를 바로 지우지 말고 서버 재설치, DNS와 네트워크 경로가 실제로 바뀌었는지 조사해.