대상 OS: Ubuntu Server 24.04 LTS

SSH 접속 실패 로그는 보안 관점에서 매우 가치가 크지만, 그대로 보면 양이 많고(노이즈), 같은 패턴이 반복되어(중복), 정작 중요한 징후(구성 오류/계정 공격/장애 전조)가 묻히기 쉽습니다. “필터링해서 의미를 뽑아내는 습관”이 있어야 로그가 진짜 자산이 됩니다.

아래는 Ubuntu(24.04)에서 systemd journal 기반으로 SSH 실패 로그를 실무에서 바로 쓰기 좋게 정리하는 방법입니다.

1) 오늘(또는 최근 1시간)의 SSH 로그만 빠르게 보기

초동 대응은 범위를 좁히는 것부터 시작합니다. 일단 “언제부터 문제가 시작됐는지”를 감으로 잡습니다.

# 오늘 발생한 ssh 서비스 로그(최근 200줄만)
sudo journalctl -u ssh --since "today" --no-pager | tail -n 200

# 최근 1시간만(장애/공격 급증 확인)
sudo journalctl -u ssh --since "1 hour ago" --no-pager | tail -n 200


2) 실패 이벤트만 남기기(키워드 필터링)

SSH 로그는 성공/실패/세션 종료가 섞입니다. 실패를 우선 분리해 “공격인지, 오타인지, 설정문제인지”를 봅니다.

# 실패/거부/무효 계정 중심으로 필터
sudo journalctl -u ssh --since "today" --no-pager   | egrep -i "failed|failure|invalid user|authentication failure|refused|disconnect"   | tail -n 200

환경마다 로그 메시지가 조금씩 다를 수 있어, 현장에서는 2~3개의 키워드를 조합해 고정합니다.


3) 반복 IP 상위 N개를 뽑아 “스캐닝/브루트포스” 감 잡기

완벽한 파서는 아니지만, 초동 대응(차단/레이트리밋/AllowList 판단)에는 매우 유용합니다.

# 오늘 ssh 로그에서 IP를 뽑아 반복 상위 20개 확인
sudo journalctl -u ssh --since "today" --no-pager   | egrep -o "([0-9]{1,3}\.){3}[0-9]{1,3}"   | sort | uniq -c | sort -nr | head -n 20

상위 IP가 몇 개에 집중되어 있으면(예: 1~2개가 대부분) 차단이 효과적일 가능성이 크고, 분산되어 있으면(수백/수천개) 단순 차단만으로는 부족할 수 있습니다.


4) “계정 공격”인지 “설정 문제”인지 빠르게 구분하기

로그에서 자주 보이는 패턴별로 의미를 정리해두면, 알림을 자동화하기도 쉬워집니다.

  • Invalid user: 존재하지 않는 계정명으로 시도(대개 자동 스캔)
  • Failed password: 비밀번호 추측 시도(패스워드 로그인 허용 시 위험)
  • Authentication refused: bad ownership or modes: ~/.ssh 권한/소유권 문제로 키 인증 실패(운영 실수)

정책적으로는 가능하면 비밀번호 로그인 비활성화, 키 인증 + allowlist(또는 VPN 경유)로 공격면을 줄이는 게 근본 대책입니다.


사례(현장에서 자주 겪는 상황)

  • 신규 서버 오픈 직후 곧바로 전세계 스캐너가 SSH를 두드려 실패 로그가 폭증(정상적인 인터넷 현실)
  • 운영자가 계정/홈 디렉터리 권한을 잘못 바꿈 → 키 인증이 전부 실패하며 장애처럼 보임
  • 방화벽은 열었는데 접속은 실패 → 실제로는 SSH 데몬 설정(허용 사용자/키/권한)이 원인

트러블슈팅(증상→원인→해결)

  • 증상: 키 인증이 갑자기 전부 실패
    원인: /home//.ssh 또는 authorized_keys 권한/소유자 오류
    해결: 디렉터리 700, 파일 600, 소유자 사용자로 복구 후 재시도
  • 증상: 실패 로그가 너무 많아 유의미한 이벤트가 안 보임
    원인: 기간/키워드/상위 IP 추출 없이 원문을 그대로 확인
    해결: --since로 범위 축소 → 실패 키워드 필터 → 상위 IP 추출의 순서로 루틴화
  • 증상: 특정 시간대에만 실패가 급증
    원인: 봇넷 스캔/크리덴셜 스터핑 또는 외부 작업(배치/모니터링)의 잘못된 인증 시도
    해결: 해당 시간대 로그를 분리해(예: --since 구간 지정) IP/계정 패턴을 확인하고, 내부 작업이면 키/계정 정책 정비, 외부 공격이면 접근 경로 축소(allowlist/VPN/포트 노출 최소화)

푸터: SSH 실패 로그는 “많이 쌓이는 로그”가 아니라 “의미를 추출해야 가치가 생기는 로그”입니다. 기간을 줄이고, 실패만 걸러내고, 반복 IP/계정 패턴을 뽑는 3단계만 습관화해도 대응 속도가 크게 올라갑니다.