SSH 하드닝 완벽 가이드: 비밀번호 끄고 공개키 인증·개인키 관리·fail2ban으로 침입 차단하기

비밀번호는 언젠가 추측되거나, 새어 나가거나, 무차별 대입으로 뚫립니다. 공개키는 이 세 가지에 원리적으로 면역입니다 — 단, 그 개인키를 끝까지 지켜낼 때만 그렇습니다.

클라우드에 새 서버 하나를 띄워 본 사람이라면 누구나 겪는 일이 있습니다. 인스턴스가 부팅되고 채 몇 분도 지나지 않아, 인증 로그에 낯선 IP들이 줄줄이 찍히기 시작합니다. 사람이 아니라 전 세계에 흩어진 자동 봇이, 쉬지 않고 22번 포트를 두드리며 흔한 아이디와 비밀번호 조합을 던지는 것입니다. 2026년 현재도 이 풍경은 조금도 달라지지 않았습니다. SSH 무차별 대입은 신규 서버에 가장 먼저, 가장 끈질기게 도착하는 공격입니다.

SSH(Secure Shell)는 서버에 원격으로 명령을 내리는 암호화된 통로이며, 동시에 서버에 대한 가장 강력한 통제권을 쥐여 주는 관문입니다. 여기가 뚫리면 공격자는 사실상 서버 전체를 손에 넣습니다. 그래서 SSH는 공격자가 가장 사랑하는 표적이고, 방어자가 가장 단단히 지켜야 할 곳입니다.

이 글에서는 SSH를 단계적으로 강철로 만드는 방법을 다룹니다. 핵심 한 가지 — 비밀번호 로그인을 완전히 끄고 공개키로만 접속하기 — 에서 출발해, 개인키를 안전하게 만들고 보관·교체·폐기하는 법, sshd 데몬을 세부적으로 조이는 법, 그리고 다단계 인증·fail2ban·권한 분리 같은 추가 방어층까지 순서대로 살펴보겠습니다. 모든 명령과 설정값은 그대로 복사해 쓸 수 있는 형태로 정리했습니다.

시작 전 한 가지 경고. SSH 설정 변경은 자기 자신을 서버 밖으로 잠가 버릴 수 있는 대표적인 위험 작업입니다. 이 글의 모든 변경은 반드시 다음 안전 절차를 지키며 진행하세요: ① 새 접속 방법이 동작함을 먼저 확인, ② 작업 내내 기존 SSH 세션을 하나 더 열어 두기, ③ 클라우드 콘솔(웹 터미널) 접근 경로를 미리 확보, ④ 실패하면 즉시 되돌릴 준비. 특히 비밀번호 로그인을 끄기 전에는, 공개키 접속이 실제로 되는지를 별도 세션에서 반드시 확인하십시오.

왜 비밀번호 인증부터 완전히 꺼야 하는가

SSH를 단단하게 만드는 수많은 조치 중에서, 효과가 가장 크고 근본적인 단 하나를 꼽으라면 망설임 없이 이것입니다. 비밀번호 인증을 끄고 공개키 인증만 허용하기. 나머지 모든 하드닝을 합친 것보다 이 한 가지가 더 큰 차이를 만듭니다. 그 이유를 정확히 짚어 보겠습니다.

비밀번호가 가진 세 가지 구조적 약점

비밀번호라는 인증 수단 자체에 다음 세 가지 약점이 박혀 있습니다.

세 약점의 공통점은, 비밀번호를 아무리 신경 써서 관리해도 약점 자체가 사라지지는 않는다는 데 있습니다. 운영의 문제가 아니라 방식의 문제이기 때문입니다.

공개키가 세 약점 모두에 면역인 까닭

공개키 인증(public key authentication)은 작동 원리부터 다릅니다. 한 번 이해하면 왜 안전한지가 분명해집니다.

이 방식은 짝을 이루는 두 개의 키를 씁니다. 개인키(private key) 와 공개키(public key) 입니다. 둘은 수학적으로 연결돼 있지만, 공개키만 보고 개인키를 역산해 낼 수는 없습니다. 개인키는 사용자가 자기 기기에 보관하고 절대 밖으로 내보내지 않으며, 공개키는 이름 그대로 공개돼도 안전해서 접속 대상 서버에 미리 등록해 둡니다.

접속할 때 서버는, 등록된 공개키에 짝이 되는 개인키를 사용자가 정말 가지고 있는지를 — 개인키를 직접 건네받지 않고도 — 수학적으로 검증합니다. 사용자는 "내가 개인키를 가졌다"는 사실을 증명할 뿐, 개인키 자체는 네트워크를 한 번도 타지 않습니다. 이 차이가 비밀번호의 세 약점을 정확히 무력화합니다.

• 추측 불가 — 개인키는 사람이 외운 게 아니라 기계가 만든 거대한 무작위 값입니다. 패턴도 없고 추측할 대상도 없습니다.
• 무차별 대입 불가 — 개인키의 경우의 수가 천문학적이라, 현실적인 시간 안에 전부 시도하는 것은 불가능합니다. 봇의 무차별 대입은 공개키 전용 서버 앞에서 그대로 멈춥니다.
• 유출 경로 차단 — 개인키는 전송되지 않으니 통신을 가로채도 얻을 게 없습니다. 피싱으로 "비밀번호를 입력하세요"라고 속여도, 애초에 입력할 비밀번호가 존재하지 않습니다.

정리하면, 비밀번호를 끄고 공개키만 허용하는 것은 SSH 무차별 대입이라는 가장 흔한 공격을 단순히 막는 게 아니라 성립 자체를 없애는 조치입니다.

결정적 단서: 개인키를 지킬 때만

다만 여기에 반드시 따라붙는 조건이 하나 있습니다. 공개키 인증의 안전성은 개인키가 안전하게 지켜진다는 전제 위에서만 성립합니다. 개인키가 유출되는 순간 이 모든 이점이 한꺼번에 무너집니다. 비밀번호는 그래도 추측이라는 과정을 거쳐야 하지만, 개인키는 손에 넣는 순간 게임이 끝납니다.

그래서 이 글의 절반은 "공개키로 전환하기"에, 나머지 절반은 "그 키를 제대로 지키기"에 할애합니다. 둘 다 갖춰야 비로소 안전합니다.

공개키 인증으로 전환하는 4단계

이제 직접 설정해 보겠습니다. 순서가 곧 안전장치입니다. 공개키 접속이 동작함을 확인하기 전에는 절대 비밀번호 인증을 끄지 마세요.

1단계 — 로컬 기기에서 키 페어 생성

키는 서버가 아니라, 서버에 접속하는 당신의 컴퓨터(로컬 기기)에서 만듭니다. 2026년 기준 권장 알고리즘은 Ed25519입니다. 참고로 아래에서 쓰는 ssh, ssh-keygen, ssh-copy-id 명령과 서버 쪽 설정은 모두 사실상 표준 구현인 OpenSSH의 것으로, 리눅스 서버에 기본 탑재된 그 SSH가 바로 이것입니다.

# 로컬 기기에서 실행: Ed25519 키 페어 생성
ssh-keygen -t ed25519 -C "your-comment-or-email"

# 생성 과정에서 두 가지를 묻습니다:
# 1) 저장 위치 (기본: ~/.ssh/id_ed25519)
# 2) 패스프레이즈 (반드시 설정 - 아래에서 설명)

이 명령은 파일 두 개를 만듭니다. id_ed25519(개인키, 절대 공유 금지)와 id_ed25519.pub(공개키, 서버에 등록할 것)입니다.

생성 도중 패스프레이즈(passphrase) 를 묻는데, 절대 빈칸으로 넘기지 말고 강한 패스프레이즈를 넣으세요. 이유는 뒤에서 자세히 다루지만 핵심만 말하면 이렇습니다. 개인키 파일이 어떤 경로로든 유출돼도, 패스프레이즈를 모르는 한 그 키를 쓸 수 없습니다. 개인키에 채우는 두 번째 자물쇠인 셈입니다.

2단계 — 공개키를 서버에 등록

만든 공개키를 서버에 올립니다. 아직 비밀번호 접속이 가능한 상태에서, 가장 간단한 방법은 ssh-copy-id입니다.

# 로컬 기기에서: 공개키를 서버에 등록
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server

# 또는 수동으로: 공개키 내용을 서버의 ~/.ssh/authorized_keys에 추가

이 작업은 공개키를 서버의 ~/.ssh/authorized_keys에 추가합니다. 이제 이 파일에 등록된 공개키에 짝이 되는 개인키를 가진 사람만 접속할 수 있게 됩니다.

3단계 — 공개키 접속 확인 (생략 절대 금지)

비밀번호를 끄기 전에, 공개키로 진짜 접속이 되는지부터 확인합니다. 이 단계를 건너뛰는 순간 자기 자신을 서버에서 잠가 버리는 사고가 일어날 수 있습니다.

# 로컬 기기에서: 공개키로 접속 시도
ssh -i ~/.ssh/id_ed25519 user@server

# 정상이면 개인키를 보호하는 패스프레이즈를 물어봅니다.
# 접속이 성공해야만 다음 단계로 넘어가십시오.

공개키 접속이 성공했고, 안전 절차대로 별도 세션도 하나 열어 둔 상태라면, 이제 비밀번호 인증을 끌 준비가 됐습니다.

4단계 — 서버에서 비밀번호 인증 끄기

서버의 SSH 데몬 설정 파일 /etc/ssh/sshd_config에서 비밀번호 인증을 비활성화합니다.

# 서버에서: /etc/ssh/sshd_config 에 다음 설정 적용
PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
UsePAM yes

설정을 바꾼 뒤에는 데몬을 재시작하기 전에 문법부터 검증하고, 재시작 후에는 반드시 새 세션으로 접속을 다시 확인합니다.

# 서버에서: 설정 문법 검증 (재시작 전 필수)
sudo sshd -t

# 문법이 정상이면 데몬 재시작
sudo systemctl restart ssh

# 그 다음, 반드시 별도의 새 세션으로 공개키 접속을 확인하십시오.
# 기존 세션은 절대 닫지 마십시오. 새 접속이 실패하면 기존 세션으로 되돌립니다.

이제 비밀번호로는 들어올 수 없고, 등록된 공개키를 가진 사람만 접속할 수 있습니다. SSH 무차별 대입 공격은 이 서버 앞에서 원리적으로 무력해졌습니다.

개인키를 안전하게 관리하기

앞서 강조했듯 공개키 인증의 안전성은 전적으로 개인키를 지키는 데 달려 있습니다. 전환이 절반이라면, 지금부터가 나머지 절반입니다.

패스프레이즈 — 개인키의 두 번째 자물쇠

개인키 파일은 그 자체가 곧 접속 권한입니다. 패스프레이즈 없이 만든 개인키라면, 그 파일을 손에 넣은 누구든 즉시 서버에 들어옵니다. 노트북을 잃어버리거나, 백업이 새거나, 기기가 침해당하면 개인키도 같이 넘어갑니다.

패스프레이즈는 바로 이 위험을 막습니다. 패스프레이즈로 보호된 개인키는 파일 자체가 암호화돼 있어, 패스프레이즈를 모르면 쓸 수 없습니다. 즉 개인키가 유출돼도 두 번째 자물쇠가 시간을 벌어 주고, 그 사이 당신은 해당 키를 폐기할 수 있습니다. 그러니 개인키에는 반드시 강한 패스프레이즈를 거세요. 이미 패스프레이즈 없이 만든 키가 있다면 다음 명령으로 나중에 추가할 수 있습니다.

# 기존 개인키에 패스프레이즈 추가/변경
ssh-keygen -p -f ~/.ssh/id_ed25519

SSH 에이전트 — 편의와 안전을 동시에

패스프레이즈를 걸면 접속할 때마다 입력해야 하는 번거로움이 생깁니다. 그런데 이 번거로움이 싫어서 패스프레이즈를 포기한다면 본말이 뒤바뀐 것입니다. 해법은 SSH 에이전트(ssh-agent)입니다. 패스프레이즈를 한 번만 입력하면, 그 세션 동안 개인키를 메모리에 안전하게 들고 있다가 반복 입력 없이 접속하게 해 줍니다. 보안은 그대로 두고 편의만 챙기는 방법입니다.

# SSH 에이전트 시작 (대개 데스크톱 환경에서 자동 실행됨)
eval "$(ssh-agent -s)"

# 개인키를 에이전트에 추가 (패스프레이즈를 한 번 입력)
ssh-add ~/.ssh/id_ed25519

# 일정 시간 후 자동으로 키를 잊도록 설정 (예: 1시간)
ssh-add -t 3600 ~/.ssh/id_ed25519

-t 옵션으로 키의 유효 시간을 제한하면, 에이전트에 키가 무한정 남아 있지 않아 더 안전합니다.

개인키 파일 권한 조이기

개인키 파일은 소유자만 읽도록 권한을 엄격히 제한해야 합니다. SSH는 개인키 권한이 너무 열려 있으면 아예 사용을 거부하는데, 이건 친절한 안전장치입니다.

chmod 600 ~/.ssh/id_ed25519        # 개인키: 소유자만 읽기/쓰기
chmod 700 ~/.ssh                    # .ssh 디렉터리: 소유자만 접근
chmod 644 ~/.ssh/id_ed25519.pub     # 공개키: 읽기 허용 가능

하드웨어 보안 키 — 가장 강한 보관

개인키 보관의 가장 강력한 형태는, 키를 파일이 아니라 물리적인 하드웨어 보안 키 안에 두는 것입니다. 이 방식에서 개인키는 하드웨어 장치 안에서 생성돼 그 안을 절대 떠나지 않습니다. 접속하려면 물리적 장치가 있어야 하고, 보통 장치를 직접 터치하는 등 물리적 확인까지 요구합니다.

이점은 명확합니다. 개인키가 파일로 존재하지 않으니, 기기가 침해당하거나 파일이 유출돼도 훔쳐 갈 키 자체가 없습니다. 장치를 물리적으로 빼앗지 않는 한 키를 쓸 수 없고, 장치가 있어도 터치 확인이 필요합니다. 피싱과 원격 침해 양쪽 모두에 매우 강한 방어이므로, 특히 중요한 서버에 접근하는 키라면 적극 고려할 가치가 있습니다.

개인키 관리 5대 원칙

지금까지의 내용을 관통하는 원칙을 한눈에 정리하면 다음과 같습니다.

• 절대 전송하지 않는다 — 이메일·메신저·클라우드 동기화로 개인키를 옮기지 마세요. 개인키는 생성된 기기를 떠나지 않는 게 원칙이고, 다른 기기가 필요하면 그 기기에서 별도의 키를 새로 만드세요.
• 공유하지 않는다 — 한 사람당, 한 기기당 별도의 키를 씁니다. 여러 명이 한 키를 공유하면 누가 접속했는지 추적이 안 되고, 한 명의 유출이 전원의 유출이 됩니다.
• 패스프레이즈를 건다 — 두 번째 자물쇠를 반드시 채웁니다.
• 권한을 엄격히 제한한다 — 파일 권한을 소유자 전용으로 둡니다.
• 가능하면 하드웨어 키를 쓴다 — 중요한 접근일수록 더 강한 보관으로.

키에도 생애주기가 있다: 교체와 폐기

개인키 관리는 잘 보관하는 것으로 끝나지 않습니다. 키에는 수명이 있고, 교체와 폐기가 그 일부입니다. 보안은 한 번의 설정이 아니라 계속 이어지는 과정이라는 사실이 여기서도 그대로 적용됩니다.

키 교체(rotation)

비밀번호를 주기적으로 바꾸듯 SSH 키도 주기적으로 교체하는 편이 좋습니다. 오래된 키일수록 그동안 어딘가로 유출됐을 가능성이 누적되기 때문입니다. 교체의 순서는 다음과 같습니다.

1. 새 키 페어를 만든다
2. 새 공개키를 서버에 등록한다
3. 새 키로 접속이 되는지 확인한다
4. 옛 공개키를 서버에서 제거한다

여기서도 안전 원칙은 동일합니다. 새 키 접속이 동작함을 확인한 뒤에 옛 키를 제거하세요. 순서를 뒤집으면 접속이 끊깁니다.

키 폐기(revocation)

다음 상황에서는 지체 없이 키를 폐기해야 합니다.

• 개인키가 유출됐거나 유출이 의심될 때
• 개인키가 든 기기를 분실하거나 도난당했을 때
• 그 키를 쓰던 사람이 더 이상 접근 권한을 가져선 안 될 때(퇴사 등)

폐기는 서버의 ~/.ssh/authorized_keys에서 해당 공개키 줄을 지우는 것으로 끝납니다. 지우는 즉시 그 키로는 더 이상 들어올 수 없습니다.

# 서버에서: authorized_keys 에서 특정 공개키 제거
# 해당 키의 줄을 찾아 삭제합니다.
# 폐기 후, 그 키로 접속이 거부되는지 확인하십시오.

앞에서 "한 사람당, 한 기기당 별도의 키"를 강조한 이유가 바로 여기 있습니다. 키가 사람·기기별로 나뉘어 있으면 문제가 된 키 하나만 폐기해 다른 접속에는 영향을 주지 않을 수 있습니다. 반대로 키를 공유했다면, 하나를 폐기하는 순간 전원이 같이 끊깁니다.

그리고 패스프레이즈가 폐기까지의 시간을 벌어 준다는 점을 다시 짚습니다. 기기를 잃어버려도 개인키에 패스프레이즈가 걸려 있으면, 그걸 모르는 습득자는 즉시 접속하지 못합니다. 그 사이 당신은 키를 폐기하면 됩니다. 패스프레이즈가 없었다면 분실과 동시에 접속 권한이 통째로 넘어갔을 것입니다.

sshd 데몬 세부 하드닝

공개키 전용으로 전환한 다음, /etc/ssh/sshd_config의 추가 설정으로 보안을 한 단계 더 끌어올릴 수 있습니다. 아래는 권장 항목과 그 이유입니다. 변경할 때마다 sshd -t로 검증하고 새 세션으로 접속을 확인하는 절차를 잊지 마세요.

root 직접 로그인 차단

PermitRootLogin no

root는 무제한 권한 계정이라, 직접 로그인을 허용하면 공격자에게 가장 큰 표적을 그대로 내주는 셈입니다. 대신 일반 사용자로 로그인한 뒤 필요할 때만 권한을 올리는 방식(sudo)을 쓰면, 일반 계정이 뚫리더라도 곧장 전권을 빼앗기지는 않고, 누가 어떤 권한 작업을 했는지 추적도 가능해집니다.

인증 시도 횟수와 타임아웃 제한

MaxAuthTries 3
LoginGraceTime 30

MaxAuthTries는 한 연결에서 허용하는 인증 시도 횟수를, LoginGraceTime은 인증을 끝내지 못한 연결을 끊기까지의 시간을 제한합니다. 자동화된 공격이 한 연결로 여러 번 시도하거나 연결을 오래 붙잡고 있는 것을 막습니다.

유휴 세션 자동 종료

ClientAliveInterval 300
ClientAliveCountMax 2

일정 시간 활동이 없는 세션을 자동으로 종료합니다. 방치된 세션이 탈취되거나, 자리를 비운 사이 무단으로 쓰이는 것을 방지합니다.

접근 가능한 사용자 명시적 제한

# 특정 사용자에게만 SSH 접근 허용
AllowUsers your-user

# 또는 특정 그룹에게만 허용
AllowGroups ssh-users

SSH로 들어올 수 있는 사용자를 명시적으로 좁히면, 시스템 계정 같은 의도치 않은 경로로의 접근 가능성을 줄입니다. 공격면을 SSH 차원에서 줄이는 작업입니다.

안 쓰는 기능 끄기

# 사용하지 않는 전달 기능 비활성화 (필요에 따라)
AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no

# 빈 비밀번호 절대 금지
PermitEmptyPasswords no

SSH는 여러 부가 기능을 제공하는데, 쓰지 않는 기능은 꺼 두는 게 공격면 축소 원칙에 맞습니다. 다만 일부 기능은 정당한 용도가 있으니, 자신의 사용 패턴을 보고 결정하세요.

강한 암호 알고리즘만 허용

오래되고 약한 암호 알고리즘은 끄고 현대적이고 강한 것만 남기는 편이 좋습니다. 구체적인 권장 목록은 시간에 따라 바뀌므로, 신뢰할 만한 최신 하드닝 가이드를 기준으로 약한 알고리즘을 걸러내는 방식을 권합니다. 위 sshd_config 항목 전반에 대해서는 Mozilla의 OpenSSH 하드닝 가이드를 기준으로 삼는 것을 추천합니다. KexAlgorithms·Ciphers·MACs에 무엇을 넣을지를 "Modern"/"Intermediate"로 나눠 복사-붙여넣기 가능한 형태로 제시하니, 외울 필요 없이 현재 권장값을 그대로 가져다 쓰면 됩니다.

그 위에 쌓는 추가 방어 계층

공개키 전용 인증과 데몬 하드닝 위에, 몇 겹의 방어층을 더 얹을 수 있습니다. 한 겹이 뚫려도 다음 겹이 버티게 하는 깊이 방어의 적용입니다.

다단계 인증(MFA)

SSH에 다단계 인증을 더하면 공개키에 더해 두 번째 인증 요소를 요구할 수 있습니다. MFA의 핵심 가치는, 설령 자격 증명이 유출되더라도 두 번째 요소가 없으면 접속을 막아 준다는 데 있습니다. 다만 MFA도 방식에 따라 피싱 저항성이 천차만별이므로, 가능하면 피싱에 강한 방식(앞서 본 하드웨어 키 등)을 우선하세요.

fail2ban — 무차별 대입 자동 차단

fail2ban은 로그를 감시하다가 반복적으로 인증에 실패하는 IP를 자동으로 차단하는 도구입니다. 쉽게 말해, 누군가 문을 계속 잘못 두드리면 그 IP를 방화벽 수준에서 일정 시간 출입금지시키는 자동 경비입니다.

# fail2ban 설치 (데비안/우분투)
sudo apt-get install fail2ban

# SSH 보호를 위한 기본 설정 예시 (/etc/fail2ban/jail.local)
# [sshd]
# enabled = true
# maxretry = 3
# bantime = 3600
# findtime = 600

이 설정은 정해진 시간(findtime) 안에 정해진 횟수(maxretry) 이상 실패한 IP를 정해진 시간(bantime)만큼 차단합니다.

현장 노트 — fail2ban을 방어의 핵심으로 착각하지 마세요. 운영 중인 서버에서 fail2ban이 차단하는 IP 수는 그 자체로 인상적이지만, 어디까지나 마지막 잡음 필터일 뿐입니다. 순서가 중요합니다. 먼저 비밀번호 인증을 끄고, 가능하면 SSH를 인터넷 노출에서 빼낸 다음, 그 위에 fail2ban을 얹는 것입니다. fail2ban만 깔아 둔 채 비밀번호 로그인은 그대로 열어 둔 서버를 적지 않게 봤는데, 이건 자물쇠는 그대로 두고 경비원만 세운 격입니다. 공개키 전용으로 이미 전환했다면 무차별 대입 자체가 무력하므로, fail2ban은 추가적인 잡음 감소와 로그 정리 효과로 이해하는 편이 정확합니다.

권한 분리와 최소 권한

SSH로 들어온 다음의 보안도 중요합니다. root 직접 로그인을 막았듯, 서버 안에서도 최소 권한 원칙을 적용하세요. 각 사용자와 프로세스가 자기 작업에 꼭 필요한 최소한의 권한만 갖게 하면, 한 계정이 침해당해도 피해가 그 권한 범위 안에 갇힙니다. 내부자 위협과 측면 이동(lateral movement) 방어에 직결되는 부분입니다.

배스천(점프) 호스트

서버를 여러 대 운영한다면, 모든 서버에 제각각 접근하는 대신 잘 보호된 단일 진입점 — 배스천 호스트(bastion host) 또는 점프 호스트 — 을 두고 그곳을 거쳐서만 내부 서버에 접근하는 구조를 고려할 수 있습니다. 외부에 노출되는 접점을 하나로 줄이고(공격면 축소), 그 하나를 집중 방어하며, 모든 접근을 한곳에서 기록·통제할 수 있다는 이점이 있습니다.

마무리 체크리스트

지금까지의 내용을 실행 항목으로 압축했습니다. 위에서 아래로 따라가면 됩니다.

• 공개키 인증으로 전환 — 키 생성 → 등록 → 접속 확인 → 비밀번호 인증 끄기 순서를 반드시 지킨다.
• 개인키에 강한 패스프레이즈 — 이미 없이 만든 키가 있으면 ssh-keygen -p로 추가한다.
• 개인키 파일 권한 조이기 — chmod 600 ~/.ssh/id_ed25519, chmod 700 ~/.ssh.
• 중요 접근엔 하드웨어 키 고려 — 개인키가 파일로 존재하지 않게 한다.
• 키 교체·폐기 절차 마련 — 사람·기기별로 키를 분리해, 유출·분실·퇴사 시 즉시 폐기할 수 있게 한다.
• sshd_config 하드닝 — root 차단, 인증 시도 제한, 유휴 종료, 사용자 제한, 약한 알고리즘 배제.
• 추가 계층 적용 — MFA, fail2ban, 최소 권한, 배스천을 위협 모델에 맞게 얹는다.
• 모든 변경에 안전 절차 — 새 경로 우선 검증, 두 번째 세션 유지, 콘솔 확보, 자동 롤백. 자기 자신을 잠그지 않는다.

SSH를 강철로 만들었다면, 다음 관심사는 자연스럽게 그 통로를 오가는 데이터의 보호 — 즉 TLS 설정으로 넘어갑니다. 1.2 이상만 허용하고 SSL Labs에서 A+를 받는 전송 계층 보안이 그다음 주제입니다.

자주 묻는 질문 (FAQ)

Q. 비밀번호 인증을 끄면 정말 더 안전한가요? 공개키 하나만 믿어도 되나요? 네, 단 개인키 관리가 전제될 때 그렇습니다. 비밀번호는 추측·무차별 대입·유출이라는 구조적 약점을 가지지만, 공개키는 이 셋에 원리적으로 면역입니다. 개인키가 네트워크를 타지 않기 때문입니다. 다만 그 안전성은 전적으로 개인키 보호에 달려 있으니, 강한 패스프레이즈와 엄격한 파일 권한(chmod 600)을 반드시 함께 적용하세요. 전환만으로는 절반이고, 키를 지키는 것이 나머지 절반입니다.

Q. 비밀번호 인증을 끄다가 서버에서 잠겨 버릴까 봐 무섭습니다. 안전하게 하는 방법은? 순서를 지키는 것이 핵심입니다. ① 공개키로 실제 접속이 되는지 먼저 확인하고, ② 작업 내내 기존 SSH 세션을 하나 더 열어 둔 상태에서, ③ 클라우드 콘솔(웹 터미널) 접근 경로를 미리 확보해 둔 뒤 비밀번호 인증을 끄세요. 설정 변경 후 데몬을 재시작하기 전에는 반드시 sudo sshd -t로 문법을 검증하고, 재시작 후에는 기존 세션을 닫지 않은 채 새 세션으로 접속을 다시 확인하세요. 새 접속이 실패하면 살아 있는 기존 세션으로 되돌리면 됩니다.

Q. Ed25519와 RSA 중 무엇을 써야 하나요? 2026년 기준으로는 Ed25519를 권장합니다. ssh-keygen -t ed25519로 만들 수 있으며, 짧은 키 길이로도 충분히 강하고 성능도 좋습니다. 기존에 RSA 키를 쓰고 있다면 당장 못 쓰는 것은 아니지만, 키 교체 시점에 Ed25519로 옮겨 가는 것을 추천합니다. 어느 쪽이든 핵심은 개인키에 패스프레이즈를 걸고 파일 권한을 소유자 전용으로 두는 것입니다.

Q. 공개키 인증으로 바꿨는데 fail2ban도 꼭 설치해야 하나요? 필수는 아닙니다. 공개키 전용으로 전환했다면 무차별 대입 공격 자체가 원리적으로 무력하므로, fail2ban은 방어의 핵심이 아니라 로그 잡음을 줄이는 보조 수단으로 보는 것이 정확합니다. SSH를 인터넷에 노출한 채 운영해야 한다면 잡음 감소 효과가 분명히 있으니 얹어 두면 좋고, 노출 경로 자체를 줄였다면 우선순위는 낮습니다. fail2ban만 깔고 비밀번호 로그인을 열어 두는 것이 가장 잘못된 조합입니다.

Q. 노트북을 잃어버렸습니다. 무엇부터 해야 하나요? 즉시 해당 키를 폐기하세요. 서버의 ~/.ssh/authorized_keys에서 그 기기의 공개키 줄을 삭제하면, 그 순간부터 해당 키로는 접속할 수 없습니다. 폐기 후에는 정말 접속이 거부되는지 확인하세요. 개인키에 패스프레이즈를 걸어 두었다면 습득자가 즉시 들어오지 못하므로 폐기까지 시간을 벌 수 있습니다. 이것이 사람·기기별로 키를 분리해 두라고 강조하는 이유이기도 합니다. 키가 분리돼 있으면 잃어버린 기기의 키 하나만 폐기하고 나머지 접속은 그대로 유지할 수 있습니다.

원문 출처 및 더 알아보기

이 글은 (주)뎁팀 웹 보안팀이 운영하는 보안 가이드 사이트 SGAEPS(시그앱스)의 가이드를 바탕으로 재구성했습니다. 더 깊은 원문은 SGAEPS 가이드 원문에서 확인하실 수 있습니다.

웹 보안 점검·긴급 대응이 필요하시면 DevTeam의 웹 긴급지원 또는 개발/보안 문의를 이용해 주세요.