SSH 로그인 뒤 관리자 명령, 같은 세션인지 확인하는 법

SSH 성공 로그와 관리자 명령 기록을 같은 사용자 이름만으로 연결해서는 안 됩니다. 호스트와 시간대, 로그인 세션 식별자, audit의 auid, 프로세스 관계를 함께 확인해야 하며, 공통 식별자가 없으면 연결은 가설로 남깁니다.

Linux audit의 auid는 원래 로그인한 사용자를 추적하는 데 쓰이고, ausearch는 로그인 세션 ID나 auid 조건으로 기록을 좁힐 수 있습니다. 이것만으로 SSH 인증 로그에 표시된 접속과 특정 명령의 인과관계가 자동 증명되는 것은 아닙니다.

계정이 같아도 접속은 두 개일 수 있습니다

SSH 로그는 원격 인증과 연결을 보여 주고, Linux audit는 감사 규칙에 걸린 시스템 행위를 보여 줍니다. 두 기록은 목적과 식별자가 다릅니다. OpenBSD sshd 설명은 들어오는 연결을 처리하기 위해 daemon이 분기되는 구조를 설명합니다. 따라서 동일 계정으로 거의 동시에 두 번 로그인했다면, 계정 이름과 분 단위 시각만으로 뒤이은 파일 변경이나 명령을 특정 로그인에 귀속하기 어렵습니다.

audit의 auid는 행위를 시작한 원래 로그인 사용자를 추적하는 값입니다. audit 검색 도구는 로그인 세션 ID를 기준으로 로그인에서 파생된 프로세스 기록을 좁힐 수 있지만, 이 식별자가 모든 SSH 배포판의 인증 로그에 같은 표기로 실린다는 뜻은 아닙니다. 운영체제, PAM, audit 설정, 로그 수집 방식이 서로 다를 수 있으므로 실제 수집 필드부터 확인해야 합니다.

두 접속을 나란히 놓고 연결 강도를 판단합니다

표의 session 숫자는 설명을 위해 만든 식별자입니다. 중요한 점은 구체적인 숫자가 아니라 같은 호스트에서 로그인 세션과 감사 행위가 일치하는지입니다. 인증 로그에 audit 세션 번호가 없고 두 로그 사이의 PID·프로세스 계보도 연결되지 않는다면, 시간 근접성만으로 어느 SSH 접속이 파일을 바꿨다고 결론 내리지 않습니다. 로그 수집 지연과 시계 차이도 시각을 어긋나게 할 수 있습니다.

연결은 공통 기준을 하나씩 확인합니다

1. 기록이 나온 호스트 이름과 부팅 구간을 맞춥니다. 서로 다른 서버의 동일 계정 기록을 한 세션처럼 합치지 않습니다.
2. 시간대를 UTC 또는 조직 기준 시간대로 통일하고, 수집 지연과 시계 오차 범위를 적습니다.
3. SSH 성공 기록에서 계정·원격 주소·포트·sshd 프로세스 식별자를 확인합니다. 인증 성공은 명령 실행의 증거가 아닙니다.
4. audit 로그인 이벤트에서 로그인 세션 식별자와 auid를 확인하고, 해당 세션 범위의 프로세스·시스템 호출 기록을 찾습니다.
5. 감사 이벤트에 나온 PID와 부모 프로세스, 실행 파일·대상 객체를 대조합니다. PID는 시간이 지나면 재사용될 수 있으므로 시각과 함께 봅니다.
6. 세션이나 프로세스의 공통 연결값이 없으면 ‘같은 접속’이라고 쓰지 말고, 추가 수집이 필요한 가설과 확인하지 못한 점을 분리합니다.

기록이 없다는 사실도 설정 맥락이 필요합니다

특정 파일이나 명령에 대한 audit 이벤트가 보이지 않는다고 행위가 없었다고 단정할 수 없습니다. 해당 동작을 기록하도록 규칙이 적용됐는지, 수집기가 로그를 전달했는지, 보존 기간 안에 있는지 확인해야 합니다. 반대로 audit 한 줄이 있다고 해서 그 명령의 목적이나 승인 여부까지 알 수 있는 것도 아닙니다. 기록은 누가·언제·무엇을 했는지 좁히는 근거이며 의도 판단은 별도 자료가 필요합니다.

복습: 무엇이 연결을 뒷받침하나요?

문제: 동일 계정의 SSH 성공 기록이 09:01과 09:02에 각각 있고, 09:03에 관리자 파일 수정 기록이 있습니다. 파일 기록에는 두 번째 로그인 세션과 같은 식별자가 있지만 원격 주소가 수집되지 않았습니다. 무엇을 말할 수 있나요?

정답: 파일 수정 이벤트가 두 번째 로그인 세션과 연결된다는 근거는 있으나, 원격 주소가 없으므로 어느 주소에서 접속했는지까지는 확정할 수 없습니다. 세션 식별자와 호스트·시각을 기록하고, 주소 귀속은 미확인으로 남깁니다.