VPS SSH 보안 설정 및 무차별 대입 공격 방지 가이드

SSH 보안을 가장 먼저 강화해야 하는 이유

SSH는 서버를 제어하는 수단이므로, 모든 공격자가 가장 먼저 노리는 관문입니다. VPS가 온라인 상태가 되는 즉시, 스캐너들은 22번 포트에서 사용자 이름과 비밀번호를 무작위로 대입하기 시작합니다. 로그를 확인하면 몇 분 안에 이러한 시도가 발생하는 것을 볼 수 있습니다. SSH 보안 강화의 핵심은 공격자가 추측할 수 있는 요소를 제거하는 것입니다. 비밀번호 로그인을 완전히 끄고, root 로그인을 비활성화하며, 암호화 키를 통해서만 접속을 허용하십시오. 이 설정을 마치면 비밀번호 자체가 존재하지 않으므로 무작위 대입 공격은 성공할 수 없습니다.

이 과정은 이미 SSH가 정상적으로 작동하고 있음을 전제로 합니다. 현재 접속이 가능하다면 보안을 강화할 수 있습니다. 각 단계를 순서대로 수행하고, 새로운 세션으로 접속이 확인될 때까지 현재 세션을 유지하십시오. 그래야 실수로 인해 서버에서 차단되는 일을 방지할 수 있습니다.

1단계: 키 인증이 먼저 작동하는지 확인하기

키 인증은 비밀번호를 키 쌍으로 대체합니다. 개인 키는 사용자의 컴퓨터에 보관하고, 공개 키는 서버에 배치합니다. 서버는 개인 키가 사용자의 컴퓨터를 떠나지 않고도 사용자가 이를 소유하고 있음을 증명합니다. 비밀번호 인증을 비활성화하기 전에 키가 정상적으로 작동하는지 확인하십시오. 그렇지 않으면 서버 접속이 차단될 수 있습니다.

사용자의 컴퓨터에서 키가 없다면 새로 생성합니다:

ssh-keygen -t ed25519

공개 키를 서버로 복사합니다:

ssh-copy-id user@your-server

그런 다음 새로운 SSH 세션을 엽니다. 비밀번호를 묻지 않고 접속된다면 키가 정상적으로 작동하는 것이며, 비밀번호 인증을 비활성화해도 안전합니다. 만약 Permission denied (publickey) 오류로 접속이 차단된다면, 해당 오류는 5가지 다른 원인을 내포하고 있으며, 다른 설정을 변경하기 전에 ssh -v 출력을 통해 어떤 원인인지 확인해야 합니다. 키 사용이 처음이거나 여러 대의 컴퓨터를 사용한다면, SSH 키 관리 기초에서 전체 모델을 확인하십시오. 장치당 하나의 키를 사용하는 방법, sshd가 요구하는 권한, 노트북 분실 시 키를 폐기하는 방법 등이 설명되어 있습니다.

단계 2: 드롭인 파일을 사용하여 sshd 강화하기

/etc/ssh/sshd_config 파일을 직접 수정하지 마십시오. Ubuntu 24.04는 /etc/ssh/sshd_config.d/ 경로에서 드롭인 파일을 읽어 들입니다. 이 방식은 작은 파일을 사용하여 깔끔하게 관리할 수 있고, 패키지 업그레이드 시에도 설정이 유지되며, 문제가 발생할 경우 쉽게 제거할 수 있습니다. 파일 이름이 중요합니다. sshd는 각 설정에 대해 가장 먼저 읽은 값을 유지하는데, Ubuntu 클라우드 이미지에는 이 디렉터리에 PasswordAuthentication yes 설정이 포함된 50-cloud-init.conf 파일이 존재합니다. 따라서 파일 이름을 00-으로 지정하여 해당 파일보다 먼저 정렬되도록 해야 우선순위를 갖게 됩니다. 99- 파일은 설정이 무시되므로 주의하십시오. 다음 명령으로 파일을 생성합니다.

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

다음 내용을 입력합니다.

# Key-only login: no passwords to guess.
PasswordAuthentication no
KbdInteractiveAuthentication no

# No direct root login. Log in as your user, then use sudo.
PermitRootLogin no

각 줄은 보안 취약점을 하나씩 차단합니다. PasswordAuthentication no 설정이 가장 중요합니다. 비밀번호 인증을 비활성화하면 무차별 대입 공격(brute-force attack)을 시도할 대상이 사라집니다. KbdInteractiveAuthentication no 설정은 비밀번호와 유사한 또 다른 인증 경로를 차단합니다. PermitRootLogin no 설정은 공격자가 단순히 모든 서버에 존재하는 root 계정을 노리는 대신, 사용자의 정확한 계정 이름과 개인 키를 모두 알고 있어야만 접근할 수 있도록 제한합니다.

3단계: 설정 테스트 및 리로드

설정을 적용하기 전에 오타로 인해 서비스가 중단되지 않도록 설정을 검사합니다.

sudo sshd -t

아무런 메시지가 출력되지 않으면 설정이 올바른 것입니다. SSH를 리로드합니다.

sudo systemctl reload ssh

그다음 sshd가 실제로 사용하는 설정을 확인하여, 다른 파일에 의해 덮어씌워진 설정이 없는지 확인합니다.

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

두 명령 모두 no을 출력해야 합니다. 이제 현재 세션을 닫지 말고, 다른 터미널에서 새 세션을 엽니다. 키를 사용하여 정상적으로 로그인된다면 완료된 것입니다. 문제가 발생하더라도 첫 번째 세션이 열려 있으므로 수정할 수 있습니다. 이 중복 연결은 안전장치이므로 절대 건너뛰지 마십시오.

단계 4: 선택 사항인 비표준 포트 사용

SSH 포트를 22번에서 2222번과 같은 다른 포트로 옮기는 것은 실질적인 보안을 강화해주지 않습니다. 집요한 공격자는 모든 포트를 스캔하기 때문입니다. 다만 대부분의 자동화된 스캐너는 22번 포트만 시도하므로, 로그에 기록되는 불필요한 접속 시도를 줄이는 효과는 있습니다. 이 설정을 원한다면 드롭인 파일에 Port 2222를 추가하십시오. 먼저 방화벽에서 새 포트를 허용하고, sudo systemctl daemon-reload && sudo systemctl restart ssh.socket을 실행한 뒤 ssh -p 2222을 사용하여 접속하십시오. Ubuntu 24.04에서는 ssh.socket가 리스닝 포트를 제어하므로, 단순히 reload ssh만 실행해서는 sshd가 22번 포트에 그대로 남습니다. 소켓을 재시작해야 새로운 포트가 적용됩니다. 이는 보안 조치가 아니라 환경을 정돈하는 작업으로 간주하십시오.

5단계: 추가 방어 계층 구성

강화된 SSH 키는 보안의 기초이며, 그 위에 두 가지 계층을 추가로 구성합니다.

Fail2ban은 로그를 모니터링하다가 인증 실패가 반복되는 주소를 차단하여, 스캐너의 소음을 줄이고 공격자를 조기에 퇴출합니다. 이는 키 기반 인증과 자연스럽게 결합됩니다. SSH 공격을 차단하기 위한 Ubuntu의 Fail2ban 설정을 참조하십시오.

더 강력한 방법은 SSH를 공용 인터넷에서 완전히 격리하는 것입니다. SSH를 WireGuard VPN 내부로 배치하고 방화벽에서 22번 포트를 터널 내부로만 제한하면, VPN 외부에서는 SSH에 접근조차 할 수 없게 되어 무차별 대입 공격이 어려워지는 수준을 넘어 불가능해집니다. 이 모든 과정은 기본적으로 모든 접근을 거부하는 방화벽이 전제되어야 하며, 이는 VPS의 UFW 설정을 통해 수행합니다.

SSH는 더 큰 체크리스트의 한 항목일 뿐입니다. 새로운 VPS를 위한 초기 10분 설정에서 단계별 순서를 확인할 수 있으며, Ubuntu의 자동 보안 업데이트를 통해 이후에도 시스템을 최신 상태로 유지할 수 있습니다. 하지만 문을 잠그는 것만으로는 그 뒤에 실행되는 서비스까지 보호할 수는 없습니다. 만약 동일한 VPS에서 비밀번호 관리자를 운영 중이라면, Vaultwarden 보안 강화를 통해 키 기반 인증이 다루지 못하는 관리자 토큰과 백업 파일까지 보호해야 합니다.

FAQ

Ubuntu 24.04에서 SSH 비밀번호 로그인을 비활성화하려면 어떻게 해야 합니까?

/etc/ssh/sshd_config.d/00-hardening.conf에 드롭인 파일을 생성하십시오. 00 접두사를 사용하면 50-cloud-init.conf보다 먼저 정렬되는데, PasswordAuthentication yes이 우선순위를 갖지 않도록 하기 위함입니다(sshd는 처음 읽은 값을 유지합니다). 이 파일에 PasswordAuthentication no과 KbdInteractiveAuthentication no를 포함하고, sudo sshd -t을 실행하여 설정을 검증한 뒤 sudo systemctl reload ssh을 수행하십시오. 설정을 적용하기 전에 새 세션에서 키 로그인이 정상적으로 작동하는지 반드시 확인하십시오. sshd_config를 직접 수정하는 대신 드롭인 파일을 사용하면 패키지 업그레이드 시에도 설정이 유지되며 되돌리기도 쉽습니다.

SSH를 통한 root 로그인을 비활성화해야 합니까?

그렇습니다. PermitRootLogin no을 설정하여 누구도 root 계정으로 직접 로그인할 수 없게 하십시오. 일반 사용자 계정으로 로그인한 뒤 관리 작업이 필요할 때 sudo를 사용하십시오. 모든 Linux 시스템에는 root 계정이 존재하므로, 이를 그대로 두면 공격자에게 알려진 사용자 이름을 제공하는 꼴이 됩니다. 비활성화하면 공격자는 사용자의 계정 이름을 알아내고 키까지 보유해야 하므로 보안성이 높아집니다.

SSH 포트를 변경하면 서버가 더 안전해집니까?

실질적인 보안 향상은 없습니다. 22번 포트만 탐색하는 단순 스캐너로부터는 숨을 수 있어 로그 노이즈는 줄어들지만, 실제 공격자는 모든 포트를 스캔하여 결국 찾아냅니다. 침입을 막는 실질적인 수단은 키 기반 인증입니다. 포트를 변경하려면 먼저 방화벽에서 새 포트를 개방한 뒤 sudo systemctl daemon-reload && sudo systemctl restart ssh.socket를 실행하십시오. Ubuntu 24.04에서는 소켓이 리스너를 소유하므로, 단순히 reload만 수행하면 sshd가 여전히 22번 포트에 머물게 됩니다.

SSH 키를 사용하면 Fail2ban이 필요 없습니까?

선택 사항이지만 여전히 유용합니다. 키 기반 인증을 사용하면 비밀번호 추측 공격이 성공할 수 없으므로, Fail2ban이 침입을 막는 핵심 수단은 아닙니다. Fail2ban은 특정 주소에서 반복되는 실패 시도를 제한하여 로그에서 스캐너 노이즈를 줄이고 반복적인 공격자를 조기에 차단합니다. 다만 느리고 분산된 공격은 차단 임계값 아래에서 계속될 수 있습니다. 키 인증을 기본으로 사용하되, 가능하면 SSH를 VPN 뒤에 두는 것이 좋습니다.

SSH 접속이 차단되면 어떻게 복구합니까?

제공업체의 웹 콘솔을 사용하십시오. 이는 SSH를 거치지 않는 시리얼 또는 VNC 연결을 통해 서버에 접근합니다. 콘솔에서 로그인한 뒤 sshd 드롭인 파일을 수정하고 서비스를 다시 로드하십시오. 이것이 바로 새 SSH 설정을 적용할 때 첫 번째 세션을 닫기 전에 두 번째 터미널에서 테스트해야 하는 이유이며, 비밀번호 로그인을 끄기 전에 키 인증이 이미 작동하고 있어야 하는 이유입니다.