VPS SSH 보안 설정 및 강화 방법 가이드

SSH를 가장 먼저 강화해야 하는 이유

SSH는 서버를 제어하는 수단입니다. 따라서 공격자가 가장 먼저 시도하는 관문입니다. VPS가 온라인 상태가 되면, 스캐너가 port 22를 대상으로 사용자 이름과 비밀번호를 무작위로 대입하기 시작합니다. 몇 분 이내에 로그에서 이러한 시도를 확인할 수 있습니다. SSH 강화의 목적은 공격자가 추측할 수 있는 요소를 제거하는 것입니다. 비밀번호 로그인을 완전히 비활성화하고, root 로그인을 비활성화하며, 암호화 키만 허용하십시오. 이렇게 설정하면 비밀번호 자체가 존재하지 않으므로 무차별 대입 공격이 성공할 수 없습니다.

이 과정은 SSH가 이미 정상 작동하고 있다는 것을 전제로 합니다. 로그인이 가능하다면 설정을 강화할 수 있습니다. 실수로 접속이 차단되는 것을 방지하기 위해, 새로운 세션이 연결될 때까지 현재 세션을 유지하며 단계를 순서대로 진행하십시오.

Step 1: 키 인증 작동 여부를 먼저 확인하십시오

키 인증은 비밀번호를 키 쌍(key pair)으로 대체합니다. 개인 키(private key)는 사용자의 컴퓨터에 보관하고, 공개 키(public key)는 서버에 저장합니다. 서버는 개인 키가 컴퓨터 외부로 유출되지 않은 상태에서 사용자가 해당 키를 보유하고 있음을 증명합니다. 비밀번호 인증을 비활성화하기 전에 키 인증이 작동하는지 반드시 확인하십시오. 그렇지 않으면 접속이 차단될 수 있습니다.

키가 없다면 사용자의 컴퓨터에서 다음 명령어로 키를 생성하십시오:

ssh-keygen -t ed25519

공개 키를 서버로 복사하십시오:

ssh-copy-id user@your-server

그 다음 새로운 SSH 세션을 실행하십시오. 비밀번호 입력 없이 접속된다면 키 인증이 정상적으로 작동하는 것이며, 비밀번호 인증을 비활성화해도 안전합니다. 키 인증이 처음이거나 여러 대의 컴퓨터를 사용하는 경우, SSH 키 관리 기초에서 전체 모델을 설명합니다. 이 문서에는 기기당 하나의 키 사용, sshd가 요구하는 권한 설정, 노트북 분실 시 키를 무효화하는 방법이 포함되어 있습니다.

Step 2: drop-in file를 사용하여 sshd 강화하기

/etc/ssh/sshd_config 파일을 직접 수정하지 마십시오. Ubuntu 24.04는 /etc/ssh/sshd_config.d/에서 drop-in 파일을 읽습니다. 해당 디렉토리에 작은 파일을 생성하는 것이 관리하기 더 깔끔하며, 패키지 업그레이드 시에도 설정이 유지됩니다. 또한 문제가 발생했을 때 제거하기 쉽습니다. 파일 이름이 중요합니다. sshd는 각 설정에 대해 가장 먼저 읽은 값을 유지합니다. Ubuntu cloud image는 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 계정을 노리는 대신, 반드시 사용자의 username을 알고 해당 key를 보유해야만 합니다.

Step 3: Test the config, then reload

설정을 적용하기 전에 오타로 인해 서비스가 중단되지 않도록 구성 파일의 오류를 확인하십시오:

sudo sshd -t

아무것도 출력되지 않으면 구성 파일이 유효한 것입니다. SSH를 재시작하십시오:

sudo systemctl reload ssh

그 다음, 다른 파일에 의해 설정이 덮어씌워지지 않았는지 확인하기 위해 sshd가 실제로 사용하는 설정을 확인하십시오:

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

두 결과 모두 no를 출력해야 합니다. 현재 세션을 종료하지 않은 상태에서, 다른 터미널을 통해 새로운 세션을 여십시오. 키를 통해 로그인이 성공하면 완료된 것입니다. 문제가 발생하더라도 기존 세션이 열려 있으므로 문제를 수정할 수 있습니다. 이 중복 세션 유지는 안전을 위한 필수 단계이므로 반드시 수행하십시오.

Step 4: 선택 사항인 비표준 포트

SSH 포트를 22에서 2222와 같은 번호로 변경하는 것이 실질적인 보안을 강화하지는 않습니다. 공격자는 모든 포트를 스캔하기 때문입니다. 이 작업의 목적은 로그 노이즈를 줄이는 것입니다. 대부분의 자동 스캐너는 22번 포트만 시도하기 때문입니다. 이 설정을 적용하려면 drop-in 파일에 Port 2222을 추가하십시오. 먼저 방화벽에서 새 포트를 허용해야 합니다. 그 다음 sudo systemctl daemon-reload && sudo systemctl restart ssh.socket을 실행하고 ssh -p 2222으로 접속하십시오. Ubuntu 24.04에서는 ssh.socket이 listening port를 관리합니다. 따라서 일반적인 reload ssh 방식으로는 sshd가 22번 포트에 그대로 남게 됩니다. 소켓을 재시작해야 새 포트가 적용됩니다. 이 설정은 보안 목적이 아닌 관리 편의를 위한 것으로 간주하십시오.

Step 5: 추가 방어 계층 구성

강화된 SSH key는 기초이며, 그 위에 두 개의 방어 계층을 추가합니다.

Fail2ban은 로그를 감시하여 반복적으로 인증에 실패하는 주소를 차단합니다. 이를 통해 스캐너의 노이즈를 줄이고 공격자를 조기에 퇴출할 수 있습니다. 이 방식은 key-only auth 방식과 함께 사용할 때 효과적입니다. Ubuntu에서 SSH 공격을 차단하기 위한 Fail2ban 설정을 참조하십시오.

가장 강력한 방법은 SSH를 공용 인터넷에서 완전히 분리하는 것입니다. 만약 WireGuard VPN을 통해 SSH를 보호하고 port 22를 터널로만 허용하도록 방화벽을 설정하면, VPN 외부의 사용자는 SSH에 접근할 수 없습니다. 이 경우 무차별 대입 공격(brute-force)은 단순히 어려워지는 것이 아니라 불가능해집니다. 이 모든 과정은 VPS에 UFW를 설정하여 기본적으로 모든 접속을 차단하는 방화벽이 작동 중임을 전제로 합니다.

SSH는 더 큰 체크리스트의 일부입니다. 새 VPS를 위한 초기 10분 가이드는 단계별 절차를 제공하며, Ubuntu의 자동 보안 업데이트는 이후 시스템을 최신 상태로 유지합니다.

FAQ

Ubuntu 24.04에서 SSH 비밀번호 로그인을 비활성화하는 방법은 무엇입니까?

/etc/ssh/sshd_config.d/00-hardening.conf 경로에 drop-in 파일을 생성하십시오. 00 접두사를 사용하면 50-cloud-init.conf보다 먼저 정렬됩니다. 50-cloud-init.conf의 PasswordAuthentication yes 설정이 우선 적용되는 것을 방지하기 위함입니다. 파일에 PasswordAuthentication no 및 KbdInteractiveAuthentication no을 포함한 후, sudo sshd -t을 실행하여 설정을 확인하고 sudo systemctl reload ssh을 수행하십시오. 설정을 적용하기 전, 새 세션에서 키 로그인이 정상 작동하는지 반드시 확인해야 합니다. sshd_config 대신 drop-in 파일을 수정하면 패키지 업그레이드 시 설정이 유지되며 복구가 쉽습니다.

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

예. PermitRootLogin no을 설정하여 root로 직접 로그인하는 것을 차단하십시오. 일반 사용자로 로그인한 뒤 관리 작업에는 sudo을 사용하십시오. 모든 Linux 시스템에는 root 계정이 존재하므로, 이 계정을 열어두면 공격자가 타겟팅할 수 있는 알려진 사용자 이름을 제공하는 셈입니다. 로그인을 비활성화하면 공격자는 사용자의 계정 이름을 알아야 하며 키를 보유해야만 합니다.

SSH 포트를 변경하면 서버 보안이 강화됩니까?

의미 있는 보안 향상은 없습니다. 22번 포트를 벗어나면 22번 포트만 스캔하는 단순 스캐너를 피할 수 있어 로그 노이즈가 줄어듭니다. 하지만 실제 공격자는 모든 포트를 스캔하여 결국 찾아냅니다. 침입을 실제로 차단하는 것은 키 기반 인증입니다. 포트를 변경할 경우, 먼저 방화벽에서 새 포트를 허용한 다음 sudo systemctl daemon-reload && sudo systemctl restart ssh.socket을 실행하십시오. Ubuntu 24.04에서는 socket이 리스너를 관리하므로, 단순 reload만으로는 sshd가 22번 포트에 머물게 됩니다.

SSH 키를 사용한다면 Fail2ban이 필요합니까?

선택 사항이지만 여전히 유용합니다. 키 기반 인증을 사용하면 비밀번호 무차별 대입 공격이 성공할 수 없으므로, Fail2ban이 공격자를 막아주는 핵심 요소는 아닙니다. Fail2ban은 단일 IP에서의 반복적인 실패 횟수를 제한하여 로그의 스캔 노이즈를 줄이고 반복적인 공격자를 조기에 차단합니다. 다만, 느린 속도로 진행되는 분산 공격은 차단 임계값 아래에서 작동할 수 있습니다. 키 인증과 함께 Fail2ban을 실행하고, 가급적 SSH를 VPN 뒤에 배치하십시오.

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

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