Ubuntu 24.04 Fail2ban 설치 및 SSH 보안 설정

Fail2ban의 실제 역할

Fail2ban은 로그를 읽는 데몬입니다. 이 데몬은 SSH 인증 메시지를 모니터링합니다. 특정 주소에서 짧은 시간 동안 여러 번 인증에 실패하면, 해당 주소를 일정 시간 동안 차단하는 firewall 명령어를 실행합니다. 이것이 Fail2ban의 핵심 원리입니다. 설정은 파일 하나에 약 30줄 정도이며, Ubuntu 24.04에서는 단 한 번의 apt 명령어로 설치가 완료됩니다. 설치 직후 별도의 설정 변경 없이도 보호 기능을 사용할 수 있습니다.

Fail2ban의 기능과 한계를 명확히 이해해야 합니다. Fail2ban은 사용자를 인증하거나 데이터를 암호화하지 않습니다. 또한 단 한 번의 정교한 로그인 시도를 막을 수 없습니다. 오직 동일한 소스에서 반복되는 시도만 차단합니다. Fail2ban은 잠금 장치가 아니라 노이즈 필터이자 속도 제한기(rate limiter)입니다. 이 도구의 목적은 port 22에 대한 지속적인 백그라운드 스캔이 CPU, 대역폭, 로그 공간을 낭비하는 것을 방지하는 것입니다. 또한 한 번에 하나의 주소만 사용할 수 있는 공격자의 속도를 늦추는 역할을 합니다.

Fail2ban이 대체할 수 없는 것

Fail2ban은 첫 번째 계층이 아닌 세 번째 계층입니다. 서버가 여전히 SSH 비밀번호 인증을 허용한다면, 수천 개의 주소로 분산된 botnet이 지속적으로 비밀번호를 추측할 수 있습니다. 각 주소의 시도 횟수가 ban threshold를 넘지 않으면 차단되지 않기 때문입니다. 이에 대한 근본적인 방어책은 key-only authentication입니다. 이 설정을 사용하면 시도 횟수와 상관없이 비밀번호 추측 공격이 불가능해집니다. key-only auth 환경에서 Fail2ban을 함께 사용하면 두 가지 이점이 있습니다. 첫째, 로그에서 brute-force 노이즈를 제거합니다. 둘째, 스캐너를 조기에 차단하여 포트 공격을 중단시킵니다. Fail2ban을 defence in depth의 관점에서 다루십시오. Fail2ban은 key authentication과 firewall 뒤에서 작동하며, 이들보다 앞서 위치하지 않습니다.

Prerequisites, and the Ubuntu 24.04 reality

root 또는 sudo 권한이 있고 SSH 접속이 가능한 Ubuntu 24.04 VPS가 필요합니다. SSH는 키 인증 방식을 사용하는 것이 좋습니다. Fail2ban은 리소스를 적게 사용합니다. RAM 사용량은 수십 MB 수준이며 별도의 제한 설정이 필요하지 않습니다.

기존 가이드들이 흔히 범하는 오류가 있습니다. 과거에는 "Fail2ban을 설치한 후 backend = systemd를 추가하라. Ubuntu에서 /var/log/auth.log를 더 이상 생성하지 않기 때문이다"라는 조언이 표준이었습니다. 이 조언은 실제 변화를 반영합니다. 최신 서버 및 클라우드 이미지는 rsyslog를 포함하지 않습니다. 따라서 SSH 로그는 systemd journal에만 기록되며 기존 텍스트 파일은 존재하지 않습니다. 하지만 Ubuntu 24.04용 Fail2ban 패키지는 이 변경 사항을 이미 반영하고 있습니다. 패키지는 /etc/fail2ban/jail.d/defaults-debian.conf를 포함하며, 서버는 업스트림 기본값이 아닌 이 파일을 실제로 사용합니다:

[DEFAULT]
banaction = nftables
banaction_allports = nftables[type=allports]
backend = systemd

[sshd]
enabled = true

이 내용을 주의 깊게 읽으십시오. 설정을 시작하기 전에 두 가지 질문에 대한 답이 됩니다. backend = systemd 설정 덕분에 SSH jail이 journal을 읽을 수 있으므로 auth.log 파일이 없어도 문제가 없습니다. banaction = nftables 설정은 차단 기능이 legacy iptables가 아닌 Ubuntu 24.04의 실제 방화벽인 nftables를 통해 수행됨을 의미합니다. 마지막으로 [sshd] enabled = true 설정은 첫 부팅부터 jail이 활성화됨을 의미합니다. 결론적으로 Ubuntu 24.04의 순정 apt install fail2ban은 즉시 SSH brute-force 공격을 차단합니다. 사용자의 주요 작업은 이를 확인하고, 정책을 조정하며, 관리자 계정이 차단되지 않도록 설정하는 것입니다.

기존의 auth.log 관련 문제는 다음 세 가지 상황에서 발생하며, 이를 인지하는 것이 중요합니다. 첫째, Fail2ban을 apt 대신 pip로 설치하여 defaults-debian.conf가 없는 경우입니다. 둘째, 읽을 수 있는 systemd journal이 없는 unprivileged container 내부인 경우입니다. 셋째, 오래된 튜토리얼을 따라 jail.local에 backend = auto를 붙여넣어 정상적인 기본 설정을 덮어쓴 경우입니다. failure-modes 섹션에서 각 상황의 구체적인 양상을 확인할 수 있습니다.

Step 1: 설치 및 차단 작동 여부 확인

sudo apt update
sudo apt install -y fail2ban

Ubuntu 24.04에는 Fail2ban 1.0.2 버전이 포함되어 있습니다. 이 패키지는 python3-systemd을(를) 필수 종속성으로 설치하므로 journal backend에 필요한 모든 구성 요소가 준비됩니다. 서비스는 자동으로 활성화되고 시작됩니다:

sudo systemctl status fail2ban

active (running) 상태여야 합니다. 현재 작동 중인 jail을 확인하십시오:

sudo fail2ban-client status sshd

공용 VPS가 외부에서 접속 가능한 상태가 된 지 몇 분만 지나도 실패 횟수가 집계되고 주소가 차단된 것을 확인할 수 있습니다. 인터넷은 지속적으로 port 22를 스캔하기 때문입니다. 이는 기본 설정이 정상 작동함을 의미합니다. 이제 처음부터 구축하는 것이 아니라 기존 설정을 최적화하는 단계입니다.

Step 2: jail.local를 수정하십시오. jail.conf를 수정하지 마십시오.

Fail2ban은 /etc/fail2ban/jail.conf에 기본 설정을 저장합니다. 해당 파일을 수정하지 마십시오. 패키지의 모든 apt upgrade이 해당 파일을 대체할 수 있으며, 수정 사항은 경고 없이 삭제됩니다. Fail2ban은 정해진 순서로 파일을 읽습니다. jail.conf를 먼저 읽고, 그 다음 jail.d/의 모든 내용을 읽으며, 마지막으로 jail.local을 읽습니다. 가장 마지막에 읽은 값이 적용됩니다. .local 파일은 사용자의 설정 파일이며, 패키지 업그레이드 시에도 변경되지 않습니다. 이 규칙은 filter에도 동일하게 적용됩니다. *.local 파일이 기본 제공되는 filter.d/*.conf 파일을 덮어씁니다.

따라서 필요한 몇 가지 설정만 변경하는 작은 jail.local 파일을 작성하십시오. jail.conf과 패키지에 포함된 jail.d/defaults-debian.conf은 참조용으로 그대로 두십시오.

Step 3: /etc/fail2ban/jail.local 작성

sudo nano /etc/fail2ban/jail.local

ignoreip 라인의 주소를 본인의 public IP로 변경하여 다음 내용을 입력하십시오:

[DEFAULT]
# Ubuntu 24.04 already sets these two in jail.d/defaults-debian.conf.
# Pinning them here documents the dependency and survives if that
# file is ever removed or changed by an upgrade.
backend   = systemd
banaction = nftables

# Ban for one hour ...
bantime  = 1h
# ... if an address fails ...
maxretry = 5
# ... 5 times within 10 minutes.
findtime = 10m

# Never ban these. PUT YOUR OWN IP HERE.
ignoreip = 127.0.0.1/8 ::1 10.0.0.24

# Longer bans for repeat offenders: 1h, 2h, 4h ... up to a week.
bantime.increment = true
bantime.maxtime   = 1w

[sshd]
enabled = true

각 설정 항목의 역할은 다음과 같습니다:

• bantime, findtime, maxretry은 정책 설정입니다. 기본값인 bantime은 10분입니다. 1시간으로 설정하는 것이 더 적절합니다. 10분 이내에 한 주소에서 5번의 실패가 발생하면 차단됩니다. 일반 사용자는 비밀번호를 한두 번 잘못 입력하지만, 10분 내 5번의 실패는 스크립트에 의한 공격입니다.
• ignoreip은 안전 장치입니다. Fail2ban이 사용자를 서버에서 차단하지 않도록, 접속하는 측의 public 주소를 여기에 입력하십시오. IP가 변경되는 가정용 연결의 경우, 마지막에 설명할 VPN 방식을 권장하지만 이 라인을 생략해서는 안 됩니다.
• bantime.increment = true은 반복되는 차단 시간을 점진적으로 늘립니다. 1시간, 2시간, 4시간 순으로 늘어나며 최대 bantime.maxtime까지 적용됩니다. 반복적으로 접속을 시도하는 주소는 차단 시간이 계속 길어집니다.

서버가 아닌, SSH 접속을 수행하는 기기에서 화이트리스트에 추가할 주소를 확인하십시오:

curl -s ifconfig.me

여기에서 포트와 차단 정책에 맞게 조정된 jail.local을 생성한 후, 파일에 붙여넣을 수 있습니다:

Step 4: Restart and verify it is reading the journal

sudo fail2ban-client -t
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

-t는 먼저 설정 테스트를 수행합니다. 따라서 jail.local에 오타가 있으면 서비스가 중단된 상태로 남는 대신 여기서 오류를 즉시 알립니다. 정상적인 jail 상태는 다음과 같습니다:

Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     14
|  `- Journal matches:  _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
   |- Currently banned: 1
   |- Total banned:     3
   `- Banned IP list:   10.0.0.66

Fail2ban이 로그인을 실제로 읽고 있는지 증명하는 숫자는 Total failed입니다. 이 숫자가 0보다 크거나, 다른 기기에서 의도적으로 로그인을 실패했을 때 숫자가 올라간다면 journal을 정상적으로 읽고 있는 것이며 설정이 완료된 것입니다. 만약 로그인을 여러 번 실패해도 0 상태를 유지하고, ignoreip 주소에서 테스트하는 것이 아님을 확신한다면 아래의 failure modes 섹션을 확인하십시오.

Journal matches 라인에 여전히 sshd.service이 표시되는 점에 유의하십시오. Ubuntu에서 SSH unit의 실제 명칭은 ssh.service입니다. 하지만 기본 제공되는 filter는 _COMM=sshd과도 일치하며, OpenSSH 24.04는 sshd이라는 이름의 프로세스에서 실패 로그를 남기므로 매칭이 정상적으로 작동합니다. 이 세부 사항은 최신 OpenSSH(9.8 이상, per-connection worker가 sshd-session인 버전)를 사용하는 경우에만 중요하며, 해당 사례는 failure modes에서 다룹니다.

Step 5: 실제 차단 사례를 확인하거나 테스트를 위해 강제로 차단하기

공용 VPS에서는 몇 분 이내에 실제 차단 사례가 발생합니다. 차단 내역을 확인하려면 로그를 tail 하십시오:

sudo tail -f /var/log/fail2ban.log

차단 로그는 다음과 같이 표시됩니다:

2026-07-15 10:31:40,502 fail2ban.filter  [812]: INFO    [sshd] Found 10.0.0.66 - 2026-07-15 10:31:40
2026-07-15 10:31:44,118 fail2ban.actions [812]: NOTICE  [sshd] Ban 10.0.0.66

기다리지 않고 전체 프로세스를 테스트하려면, 문서용 주소를 수동으로 차단하십시오. 본인의 주소를 차단하지 마십시오:

sudo fail2ban-client set sshd banip 10.0.0.66

1가 출력되며, 해당 주소가 fail2ban-client status sshd의 Banned IP list 아래에 나타납니다. 이제 방화벽에 차단이 실제로 적용되었는지 확인하십시오. Ubuntu 24.04에서는 iptables가 아닌 nftables를 사용합니다:

sudo nft list table inet f2b-table

10.0.0.66를 포함하는 addr-set-sshd 이름의 set과, 해당 set의 모든 source를 거부하는 f2b-chain chain이 표시됩니다. 만약 fail2ban-client에는 주소가 차단되었다고 나오지만 nft list에 아무것도 나타나지 않는다면, 차단 동작이 방화벽 설정과 일치하지 않는 것입니다. 실패 모드(failure modes) 섹션의 nftables/iptables 주의 사항을 참조하십시오.

Step 6: 자신을 차단 해제하고, 접속이 차단된 경우 복구하는 방법

실수로 자신의 IP 주소를 차단한 경우, 다음 명령어로 차단을 해제하십시오:

sudo fail2ban-client set sshd unbanip 10.0.0.66

성공하면 1을 반환합니다. 모든 jail의 모든 차단을 해제하려면 다음 명령어를 사용하십시오:

sudo fail2ban-client unban --all

이미 연결된 SSH 세션이 유지될 것이라고 기대해서는 안 됩니다. nftables 차단은 차단된 주소에서 port 22로 오는 모든 패킷을 거부합니다. 여기에는 기존의 established connections도 포함됩니다. 따라서 차단이 적용되는 즉시 기존 세션은 중단됩니다. 만약 자신을 차단했는데 ignoreip 항목이 없다면, 차단이 만료될 때까지 접속이 불가능합니다. 이 경우 SSH를 거치지 않는 서비스 제공업체의 웹 콘솔(VNC 또는 serial)을 통해 복구해야 합니다. 거기서 bantime 동안 기다리거나 차단 해제 명령어를 실행하십시오.

Step 7: 차단 상태를 유지하고 강화하기

Fail2ban은 활성 차단 정보를 /var/lib/fail2ban/fail2ban.sqlite3에 있는 작은 SQLite 데이터베이스에 저장합니다. 따라서 서비스 재시작이나 시스템 재부팅 후에도 차단 상태가 유지되며 데이터가 손실되지 않습니다. 이미 추가한 bantime.increment 설정은 반복되는 위반자에 대해 차단 시간을 점진적으로 늘립니다. 차단 시간은 1시간에서 시작하여 약 1주일까지 두 배씩 증가합니다.

여기에 시스템 전체에 적용되는 "3회 위반" 정책을 추가하려면, Fail2ban에서 제공하는 recidive jail을 사용하십시오. 이 jail은 자체 /var/log/fail2ban.log를 감시하며, 모든 jail에서 반복적으로 차단된 IP 주소에 대해 긴 차단 시간을 부여합니다. 현재 [DEFAULT]이 systemd backend를 사용하므로, 이 jail이 읽어야 하는 로그 파일로 경로를 고정해야 합니다.

[recidive]
enabled  = true
backend  = auto
logpath  = /var/log/fail2ban.log
bantime  = 1w
findtime = 1d
maxretry = 5

명시적인 logpath을 포함한 backend = auto 설정은 recidive이 일반 fail2ban.log 파일을 계속 읽도록 유지합니다. Ban 항목이 실제로 기록되는 곳은 이 파일입니다. 전역으로 설정한 systemd 기본값은 해당 항목이 존재하지 않는 journal을 가리키게 됩니다.

Step 8: SSH 키 인증과 VPN 조합 사용하기

Fail2ban은 SSH 키 인증을 사용할 때 가장 효과적입니다. /etc/ssh/sshd_config.d/ 하위의 /etc/ssh/sshd_config.d/00-hardening.conf 파일에 다음 내용을 설정하십시오.

PasswordAuthentication no
KbdInteractiveAuthentication no

설정 후 sudo systemctl restart ssh을 실행하십시오. 비밀번호 인증을 비활성화하면 무차별 대입 공격(brute force)이 원천적으로 차단됩니다. 이때 Fail2ban은 로그 노이즈를 줄이고 스캐너를 조기에 차단하는 용도로 사용됩니다. 보안을 더욱 강화하려면 SSH를 공용 인터넷에서 완전히 격리하십시오. 자체 호스팅 WireGuard VPN 뒤에 SSH 배치를 수행하고 방화벽으로 port 22를 설정하여 터널을 통해서만 접속을 허용하십시오. 접속할 수 없는 port에 대해서는 무차별 대입 공격이 불가능하므로, Fail2ban은 최전방 방어선이 아닌 보조 방어 수단이 됩니다.

Fail2ban은 SSH 전용이 아닙니다. 로그인 실패 로그를 생성하는 모든 서비스에 jail을 설정할 수 있습니다. 메일 서버, nginx 사이트, 또는 credential stuffing 공격으로부터 보호해야 하는 자체 호스팅 Vaultwarden 비밀번호 관리자 등이 해당됩니다. 웹 애플리케이션을 Let's Encrypt 인증서가 적용된 nginx 사이트 뒤에 배치했다면, SSH jail이 journal을 참조하는 것과 동일한 방식으로 해당 웹 앱의 access log를 Fail2ban 필터로 지정하십시오.

Failure modes, with the exact strings you will see

"Have not found any log file for sshd jail" 오류가 발생하며 Fail2ban이 시작되지 않습니다. 이는 기존의 auth.log 문제입니다. Ubuntu 24.04에서는 패키지의 기본 설정이 변경된 경우에만 발생합니다. pip 설치 시 defaults-debian.conf가 없거나, journal이 없는 container를 사용하거나, jail.local에 잘못된 backend = auto를 붙여넣은 경우입니다. /var/log/auth.log가 없는 file backend를 사용하면 sshd jail이 로그를 찾을 수 없어 데몬 전체가 중단됩니다. fail2ban.log의 출력은 다음과 같습니다:

ERROR   Failed during configuration: Have not found any log file for sshd jail

이 오류는 치명적이므로 서비스가 실행되지 않습니다. 이후 fail2ban-client status에서 다음과 같은 증상이 보고됩니다:

ERROR  Failed to access socket path: /var/run/fail2ban/fail2ban.sock. Is fail2ban running?

"socket path"라는 문구는 Fail2ban 자체의 결함이 아닙니다. 하나의 jail이 로그를 찾지 못해 서비스가 시작되지 않았음을 의미합니다. Ubuntu 패키지가 이미 설정해 둔 [DEFAULT] 내의 backend = systemd를 설정하면 두 메시지가 모두 해결됩니다.

Jail은 활성화되어 있으나 Total failed 수치가 변하지 않습니다. 데몬은 실행 중이고 journal을 읽고 있지만, journalctl -u ssh에는 실제 실패 사례가 쌓이는 반면 카운터는 0에 머물러 있습니다. 먼저 명백한 원인을 확인하십시오. ignoreip에 등록된 주소로 테스트 중이라면, 설계상 본인의 실패는 제외됩니다. 그 문제가 아니라면, OpenSSH 빌드 버전이 sshd-session (9.8 이상)인 경우입니다. 이 버전의 journal _COMM는 sshd-session이며 sshd가 아니므로, 기본 match 설정이 이를 놓칩니다. [sshd] 블록의 match 범위를 넓히십시오:

[sshd]
enabled      = true
backend      = systemd
journalmatch = _SYSTEMD_UNIT=ssh.service + _COMM=sshd + _COMM=sshd-session

서비스를 재시작하고, ignoreip에 포함되지 않은 주소로 의도적인 로그인 실패를 수행하여 Total failed 수치가 올라가는지 확인하십시오.

본인이 차단되었습니다: Connection refused. ignoreip에서 본인의 주소를 누락한 상태로 여러 번 로그인에 실패하면 다음과 같은 상황이 발생합니다:

ssh: connect to host 10.0.0.10 port 22: Connection refused

조용히 타임아웃이 발생하는 대신 거부되는 것은 nftables action의 기본 reject 판정이 작동한 결과입니다. Step 6와 같이 해결하십시오. 차단되지 않은 다른 주소의 세션이나 provider console을 통해 unban을 수행하십시오. 차단된 주소에서 이미 열려 있는 세션은 응답이 멈춥니다. 그 후 다시는 이런 일이 발생하지 않도록 주소를 ignoreip에 추가하십시오.

Fail2ban은 주소가 차단되었다고 표시하지만, 여전히 연결이 가능합니다. status sshd의 카운터는 올라가지만 주소가 여전히 port 22에 접속할 수 있습니다. 이는 ban-action과 firewall 간의 불일치 문제입니다. Ubuntu 24.04에서는 iptables 레이어가 없는 시스템에서 이전 가이드의 banaction = iptables-multiport를 사용하여 작동 중인 banaction = nftables를 덮어썼을 때 거의 항상 발생합니다. fail2ban.log의 출력은 다음과 같습니다:

fail2ban.actions [812]: ERROR  Failed to execute ban jail 'sshd' action 'iptables-multiport'

해당 설정을 삭제하고 패키지에 포함된 nftables action을 사용하십시오. 만약 ufw를 통해 방화벽을 완전히 관리하고 차단 내역이 ufw에 나타나기를 원한다면, [DEFAULT]에서 banaction = ufw를 설정하십시오. 재시작 후 sudo nft list ruleset | grep f2b를 통해 규칙이 적용되었는지 확인하십시오.

jail.local 수정 후 Fail2ban이 시작되지 않습니다. 잘못된 헤딩이나 잘못된 시간 값과 같은 오타로 인해 서비스가 실행되지 않습니다. 실행 전에 Fail2ban이 설정을 검사하도록 명령하십시오:

sudo fail2ban-client -t

이 명령은 Errors in jail 'sshd'. Skipping...과 같이 문제가 있는 파일과 jail의 이름을 알려주므로, 추측 대신 정확한 원인을 수정할 수 있습니다.

FAQ

Ubuntu 24.04의 기본 Fail2ban 설치본이 실제로 SSH 공격을 차단합니까?

그렇습니다. 해당 패키지에는 /etc/fail2ban/jail.d/defaults-debian.conf이 포함되어 있습니다. 이 설정은 sshd jail을 활성화하고, 존재하지 않는 /var/log/auth.log 대신 systemd journal을 읽도록 backend = systemd을 설정하며, Ubuntu의 실제 방화벽을 통해 차단이 적용되도록 banaction = nftables을 설정합니다. 기본 apt install fail2ban 설정만으로도 첫 부팅부터 SSH를 보호할 수 있습니다. sudo fail2ban-client status sshd 명령어로 Total failed 값이 0이 아닌지 확인하십시오.

왜 내 서버에서 Fail2ban이 아무것도 차단하지 않습니까?

다음 세 가지 일반적인 원인을 순서대로 점검하십시오. 첫째, ignoreip 주소에서 테스트 중일 수 있습니다. 이 주소는 설계상 차단 대상에서 제외됩니다. 둘째, 오래된 가이드의 backend = auto을 jail.local에 붙여넣어 기본 설정을 덮어썼을 수 있습니다. 이 경우 auth.log가 없는 이미지에서는 journal 읽기가 실패합니다. 셋째, systemd journal을 읽을 수 없는 컨테이너 환경일 수 있습니다. fail2ban-client status sshd에서 Total failed을 확인하십시오. journalctl -u ssh에 실제 실패 기록이 있음에도 값이 상승하지 않는다면, jail이 잘못된 위치를 읽고 있는 것입니다.

내 IP 주소의 차단을 어떻게 해제합니까?

성공 시 1을 반환하는 sudo fail2ban-client set sshd unbanip YOUR.IP.HERE을 실행하거나, 모든 차단을 해제하려면 sudo fail2ban-client unban --all을 실행하십시오. SSH 접속이 차단된 경우, 서비스 제공업체의 웹 콘솔 또는 VNC 콘솔을 사용하여 동일한 명령어를 실행하십시오. 차단이 적용되면 해당 주소에서 port 22로 오는 모든 패킷이 거부되므로, 이미 연결된 세션도 끊어집니다. 이후 재발 방지를 위해 해당 주소를 ignoreip에 추가하십시오.

jail.conf와 jail.local의 차이점은 무엇입니까?

jail.conf은 Fail2ban의 업스트림 기본 설정을 담고 있습니다. 패키지 업데이트 시마다 내용이 덮어씌워지므로 이곳을 수정하면 설정이 유실됩니다. Debian/Ubuntu 패키지는 jail.d/defaults-debian.conf을 통해 자체 설정을 추가합니다. 사용자의 변경 사항은 jail.local에 작성해야 합니다. 이 파일은 가장 마지막에 읽히므로 다른 설정보다 우선 적용되며, 업데이트 시에도 변경되지 않습니다. jail.conf은 참조용으로만 사용하십시오.

Fail2ban이 키 기반 SSH 인증을 대체합니까?

아니요. Fail2ban은 한 주소에서 발생하는 반복적인 실패 횟수를 제한합니다. 각 주소가 임계값 미만으로 유지되는 느린 분산 공격에는 대응할 수 없습니다. 키 전용 인증(PasswordAuthentication no)을 사용하면 비밀번호 무차별 대입 공격을 근본적으로 차단할 수 있으며, Fail2ban은 로그 노이즈를 줄이고 스캐너를 조기에 차단하는 역할을 합니다. 두 방법을 모두 사용하고, 가급적 SSH를 공용 인터넷에서 완전히 격리하는 것이 좋습니다.