팔로우 Debian과 Ubuntu에서는 sshd가 /var/log/auth.log에 기록합니다. RHEL, Rocky, Alma, CentOS Stream에서는 /var/log/secure에 기록합니다. 파일이 없으면 시스템 로그는 systemd 저널에만 있습니다. Debian 기반 시스템에서는 journalctl -u ssh, Red Hat 계열, Fedora, Arch에서는 journalctl -u sshd 명령을 사용합니다.
SSH는 거의 모든 Linux 서버의 입구이며, 그 로그는 거의 모든 Linux 조사에서 나타납니다. Prime Core에는 이러한 Linux 인증 로그에서 실행되는 11,632개의 시그마 규칙이 있으며, 643개의 MITRE ATT&CK 기술에 매핑되어 있습니다. 그중 일부는 무차별 대입 공격(T1110), 도난당한 자격 증명을 사용한 로그인(T1078), SSH를 통한 횡적 이동(T1021.004)입니다. 아래는 sshd 로그를 찾고 내보내고 정리하여 LogTotal에서 무료로 조사하는 방법입니다.
요약
| 배포판 계열 | 로그 파일 | 저널 명령 |
|---|---|---|
| Debian, Ubuntu | /var/log/auth.log | journalctl -u ssh |
| RHEL, Rocky, Alma, CentOS Stream | /var/log/secure | journalctl -u sshd |
| Fedora, Arch, rsyslog가 없는 최소 설치 | 기본값 없음 | journalctl -u sshd |
시작하기 전에: 로그를 실제로 읽을 수 있나요?
인증 로그는 의도적으로 잠겨 있어서 일반 계정은 보통 아무 것도 받지 않습니다.
- Debian과 Ubuntu의 /var/log/auth.log는 root와 adm 그룹이 읽을 수 있습니다.
- Red Hat 계열의 /var/log/secure는 root 전용입니다.
- 시스템 저널은 root와 systemd-journal, adm, wheel에 속한 사용자에게 열려 있습니다. 다른 사용자들은 자신의 사용자 저널만 볼 수 있습니다. 일반 사용자가 journalctl -u ssh를 실행하면 빈 결과가 나옵니다. 권한 문제이지 서버가 조용한 것이 아닙니다.
간단한 해결책은 sudo입니다. 로그 수집용 계정을 설정하는 경우 root 권한을 부여하지 않고 adm 또는 systemd-journal에 추가하십시오. [Linux 로그 권한 가이드]에서 자세한 내용을 다룹니다.
서버에서 무언가를 복사하기 전에 주의할 점: auth 로그에는 사용자 이름, 원본 IP, 호스트 이름이 포함됩니다. LogTotal은 업로드를 정리하지만 먼저 데이터 처리 정책을 확인하십시오.
1단계: 파일, 저널 또는 둘 다?
위의 표는 기본값을 나타내며, 기본값은 클라우드 이미지와 강화 스크립트가 변경하기 좋아하는 것입니다. 확인에 10초 정도 할애하십시오:
ls -l /var/log/auth.log /var/log/secure 2>/dev/null
systemctl is-active rsyslog
파일이 표시되고 rsyslog가 활성화되어 있으면 둘 다 있습니다: rsyslog는 저널에서 메시지를 꺼내 평문 파일에 복사합니다. 어느 소스나 작동하며 파일이 복사하기 쉽습니다.
파일이 없다면 rsyslog가 설치되지 않은 것입니다. 현재는 표준입니다: Debian 12부터 rsyslog는 기본 설치에 포함되지 않으므로, 새로 설치한 Debian 박스에는 auth.log가 전혀 없습니다. Fedora와 Arch도 몇 년간 이 방식으로 작동해 왔습니다. 2b단계로 이동하십시오.
여기 있는 동안, 저널이 재부팅 후에도 살아남는지 확인하십시오:
ls -d /var/log/journal
디렉토리가 없으면 journald가 /run/log/journal에 메모리로 로그를 저장하며, 재부팅 시 삭제됩니다. 조사 중인 머신에서는 ‘그냥 재시작 하자’라는 결정을 하기 전에 이를 아는 것이 중요합니다.
또 하나의 사건 대응 포인트: 컴퓨터가 손상될 수 있다면 로컬 로그도 손상될 수 있습니다. auth.log를 삭제하거나 편집하는 것은 고전적인 정리 단계입니다. 서버가 로그를 SIEM으로 포워드하는 경우에도 그곳에서 내보내고 비교하십시오. [Splunk 내보내기 안내서]에 방법이 설명되어 있습니다.
2a단계: auth.log 또는 secure에서 내보내기
현재 파일은 최근 며칠만 다룹니다. 오래된 항목은 회전된 파일에 있습니다. Debian과 Ubuntu에서는 auth.log.1, auth.log.2.gz와 같은 형식입니다. Red Hat 계열에서는 날짜와 함께 secure-20261012와 같은 형식을 가집니다. 사건이 지난주에 시작된 경우, 그것들도 필요합니다.
현재 및 회전된 파일에서 sshd 라인을 가장 오래된 것부터 하나의 파일로 가져옵니다:
# Debian / Ubuntu
sudo zgrep -h ‘sshd’ $(ls -tr /var/log/auth.log*) > web-03_sshd.log
# RHEL / Rocky / Alma
sudo zgrep -h ‘sshd’ $(ls -tr /var/log/secure*) > web-03_sshd.log
zgrep은 평문 및 gzip 압축 파일을 모두 읽어 들이므로 아무 것도 풀 필요가 없습니다. ls -tr은 수정 시간순으로 정렬하여 가장 오래된 파일이 먼저 오게 하고 출력은 대략적으로 연대순으로 유지됩니다. sshd 패턴은 또한 sshd-session과 일치하여 최신 시스템에서 중요합니다(2b단계 참조).
왜 필터링을 합니까? 잡음을 줄이는 것 외에도, auth.log는 sudo도 기록하며, sudo 라인에는 전체 명령 줄이 포함됩니다. 때때로 사람들이 암호를 입력할 때도 있습니다. sshd로 필터링하면 파일에서 이를 차단할 수 있습니다. 예외는 공격자가 로그인한 후 에 했던 일을 조사하고 있을 때입니다. 그때는 sudo 라인도 필요합니다: 전체 파일을 가져와 LogTotal의 정리 단계에서 그 일을 시킵니다.
업로드 전에 간단히 확인하십시오:
wc -l web-03_sshd.log
head -3 web-03_sshd.log; tail -3 web-03_sshd.log
타임스탬프를 확인하십시오. rsyslog 구성에 따라, 타임스탬프는 전통적인 syslog 형식(Oct 19 10:15:01, 연도 및 시간대 없음)이거나 완전한 ISO 8601 형식입니다. 전통적인 형식이면 서버의 시간대를 기록하십시오(timedatectl). 그렇지 않으면 이러한 이벤트를 다른 것과 일치시키려고 할 때 필요할 것입니다.
2b단계: systemd 저널에서 내보내기
저널 전용 시스템에서는 이게 전부입니다:
sudo journalctl -u ssh -u sshd
–since “2026-10-19 00:00” –until “2026-10-20 00:00”
–no-pager -o short-iso > web-03_sshd.log
여기에서 몇 가지 선택은 의도적입니다.
양쪽 단위 이름입니다. 서비스는 Debian과 Ubuntu에서는 ssh, 거의 모든 곳에서는 sshd로 호출됩니다. journalctl은 반복되는 -u 플래그를 OR과 결합하여 동일한 명령을 양쪽 계열에서 모두 작동하도록 합니다.
태그가 아닌 단위로 필터링하십시오. 이전 가이드 중 상당수는 journalctl -t sshd를 사용합니다. OpenSSH 9.8 이후, 서버는 두 개의 실행 파일로 나뉘며, 로그인과 같은 연결 메시지를 포함하여 메시지가 sshd-session으로 태그됩니다. 태그로 필터링하면 정확히 필요한 줄을 놓칩니다. 2024년에 9.8이 도입되면서 많은 fail2ban 및 sshguard 설정이 깨졌습니다. RHEL 10 및 기타 최신 릴리스는 OpenSSH 9.8 또는 최신 버전을 제공합니다. 단위로 필터링하면 서비스를 수행하는 모든 프로세스를 잡을 수 있으며, 그것이 무엇으로 불리든 관계없습니다.
-o short-iso. 완전한 ISO 8601 타임스탬프(연도 및 시간대 포함)가 있는 syslog 스타일의 행을 제공합니다. 따라서 추측할 필요가 없습니다. [확인: LogTotal이 short-iso를 구문 분석하는지 확인하십시오. 그렇지 않으면 기본값 -o short를 사용하십시오]. 모든 저널 필드를 유지하려면 (PID, 부트 ID, 호스트 이름 등) -o json을 사용하여 각 줄에 하나의 JSON 개체를 기록하십시오. 파일은 더 커지지만 아무 것도 손실되지 않습니다.
시간 필터는 상대적인 값도 취합니다: –since “2 hours ago” 또는 –since yesterday를 사용할 수 있습니다. 지속적인 저널과 함께 -b -1은 사건 후에 서버가 다시 시작되었던 경우 이전 부팅으로 출력을 제한합니다.
/var/log/journal에서 이진 .journal 파일을 복사하여 업로드하지 마십시오. LogTotal은 텍스트 및 JSON을 읽으며 저널 파일은 둘 다 아닙니다.
파일을 확보하고 나서 찾아야 할 것
대부분의 sshd 라인은 몇 가지 패턴으로 나뉩니다.
| 라인 시작 | 의미 |
|---|---|
| Failed password for <user> from <ip> | 존재하는 계정에 잘못된 비밀번호 |
| Invalid user <user> from <ip> | 사용자 이름이 존재하지 않음; admin, test, oracle 등의 스캐너 순환에 흔함 |
| Accepted password for / Accepted publickey for | 성공적인 로그인; publickey 라인에는 키의 SHA256 지문도 포함됩니다 |
| Disconnecting authenticating user … Too many authentication failures | 클라이언트가 MaxAuthTries에 도달했습니다 |
| Connection closed by <ip> … [preauth] | 인증 전 드롭, 보통 스캐너와 배너 그래버 |
| pam_unix(sshd:session): session opened for user | 세션이 실제로 시작됨 |
멈춰야 할 가치가 있는 시퀀스: 한 IP에서 Failed 또는 Invalid user 라인이 연이어 발생한 후, 동일한 IP에서 Accepted가 되는 경우. 이는 성공한 무차별 대입 공격입니다. 그뒤로: 서비스 계정에 대한 승인, 아무도 모르는 주소에서, 아무도 일하지 않는 시간에.
OpenSSH 9.8 이상에서는 패널티에 대한 메시지도 볼 수 있습니다: sshd는 이제 인증에 계속 실패하는 주소를 일시적으로 거부합니다. 이것들은 증상으로 간주하십시오. 누군가가 포트를 때리고 있었다는 것을 말해주는 것으로, 누군가가 들어갔다는 것을 알리는 것이 아닙니다.
LogTotal에 업로드하여 정리하고 검토하십시오
수백 줄을 눈으로 읽는 것은 괜찮습니다. 하지만 40,000 줄을 읽는 것은 그렇지 않습니다. LogTotal은 로그 파일에 대한 감지 논리를 실행하기 위해 아무 것도 설정하지 않고 사용하는 SOC Prime의 무료 서비스입니다. 업로드한 파일을 정리하고 파일을 보관하지 않습니다.
- 업로드 하십시오. logtotal.com 을 열고 web-03_sshd.log를 끌어다 놓습니다. [확인: 업로드 화면, 크기 제한]
- 정리하십시오. [PROOF: what gets masked in an sshd log: usernames, source IPs, hostnames]. Look over the result before you go on. You know which of those names are sensitive in your environment.
- 검토하십시오. [PROOF: what the results screen shows and how findings map to rules and ATT&CK techniques]
진짜 데이터에서 그의 모습 테스트용 VM에서 sshd 로그를 생성했습니다: [확인: 예를 들어, 몇 가지 일반적인 사용자 이름에 대한 SSH 비밀번호 분무(run), 성공적인 로그인 하나로 종료] 파일은 [확인: N 줄, X KB]로 나왔습니다. LogTotal은 [확인: 실제 발견 내용, 일치한 규칙, ATT&CK 기술]을 플래그했습니다.
자신의 서버를 만지기 전에 한번 해보고 싶다면? [확인: 샘플 파일 링크]는 우리가 위에서 사용한 동일한 파일입니다.
잘못될 때
| 증상 | 가능한 원인 | Fix |
|---|---|---|
| auth.log에 대한 파일 또는 디렉터리가 없습니다 | rsyslog가 설치되지 않음(Debian 12 이후 기본값) | journalctl 사용, 2b단계 |
| 로그 파일에 대한 권한이 거부됨 | auth.log는 adm 전용, secure는 root 전용 | sudo 사용, 또는 계정을 adm에 추가 |
| journalctl -u ssh가 다른 사용자의 힌트와 함께 아무 것도 반환하지 않음 | systemd-journal, adm 또는 wheel에 속하지 않았습니다 | sudo 사용, 또는 계정을 systemd-journal에 추가 |
| 루트로 journalctl -u ssh가 아무 것도 반환하지 않음 | 이 배포판의 잘못된 단위 이름 | -u ssh -u sshd 사용 |
| Logouts are there, but no Accepted lines | OpenSSH 9.8+에서 태그(-t sshd)로 필터링 | 대신 단위로 필터링 |
| 마지막 재부팅 이전의 것은 없음 | 휘발성 저널; /var/log/journal 없음 | 옛 로그는 사라졌습니다; SIEM 또는 로그 포워더를 확인하십시오 |
| 파일이 며칠 분만 담김 | 회전된 파일이 포함되지 않음 | auth.log* 또는 secure*로 zgrep 명령 사용 |
| 타임스탬프가 다른 소스와 맞지 않음 | 고전적인 syslog 타임스탬프에는 시간대가 포함되지 않음 | 서버의 시간대를 기록하거나 -o short-iso로 내보내십시오 |
FAQ
Ubuntu에서 SSH 로그는 어디에 있습니까?
표준 Ubuntu 설치에서는 /var/log/auth.log에 있으며 저널에도 있습니다(journalctl -u ssh). 최소 클라우드 이미지는 때때로 rsyslog를 생략할 수 있습니다. 파일이 없으면 저널을 사용하십시오.
실패한 SSH 로그인만 보려면 어떻게 해야 합니까?
저널 시스템에서는 sudo journalctl -u ssh -u sshd | grep -E ‘Failed|Invalid user’를, 파일이 있는 경우에는 sudo zgrep -hE ‘Failed|Invalid user’ /var/log/auth.log*를 사용하십시오. 신속한 확인을 넘어선 경우 전체 sshd 로그를 업로드하십시오. 실패는 성공과 비교해야 의미가 있습니다.
last와 lastb는 무엇입니까?
이들은 /var/log/wtmp 및 /var/log/btmp의 이진 로그인 기록을 읽습니다. 로그인한 사람을 신속히 확인하는 데는 유용하지만, sshd의 자체 로그에 비해 세부 정보가 훨씬 적으며, 침입자가 쉽게 변조할 수 있습니다.
여러 서버에서 한 번에 sshd 로그를 수집하려면 어떻게 해야 하나요?
단발성으로 루프가 가능합니다: for h in web-01 web-02 web-03; do ssh “$h” “sudo journalctl -u ssh -u sshd –since yesterday -o short-iso –no-pager” > “${h}_sshd.log” done 원격 측에서 비밀번호 프롬프트 없이 작동하려면 sudo가 필요합니다. 그렇지 않으면 ssh에 -t을 추가하고 매번 입력하십시오. 분기마다 한 번 이상 수행하는 경우 로그를 SIEM으로 전송하십시오.
sshd 로그를 온라인 도구에 업로드해도 괜찮나요?
LogTotal은 업로드를 분석 전에 정리하며 파일을 유지하지 않습니다. [정리 가이드]에서 마스킹되는 내용을 볼 수 있습니다. 회사의 데이터 처리 규칙이 항상 우선입니다.
다음 단계
파일을 가져오셨나요? LogTotal에 업로드하여 11,632개의 시그마 규칙이 무엇을 만들어내는지 확인하십시오. 전체 Linux 서버에서 감지 논리가 한 번에 하나의 파일이 아닌 방식으로 실행되길 원하신다면.
참조
- Debian 12 릴리스 노트: 시스템 로깅의 변경 사항
- OpenSSH 9.8 릴리스 노트: sshd / sshd-session 분할과 로그 태그 변경
- journalctl(1): 단위 필터, 출력 형식, 저널 접근 그룹
- journald.conf(5): 지속적 대 휘발성 저장소
