sshd 하드닝의 순서와 검증

한 줄 요약

sshd 설정을 바꿀 때 가장 중요한 것은 어떤 값을 넣느냐가 아니라 어떤 순서로 확인하느냐다. 잘못하면 자기 자신을 잠근다.

왜 이게 필요했나

원격 서버의 sshd 설정을 고치는 것은 타고 있는 나뭇가지를 자르는 일과 같다. 설정이 틀리면 sshd 가 안 뜨고, 안 뜨면 들어갈 방법이 없다. 콘솔 접근이 없는 클라우드 인스턴스라면 인스턴스를 통째로 재생성해야 할 수도 있다.

그래서 절차가 있다.

1. 현재 세션을 유지한 채 새 터미널을 하나 더 열어 둔다
2. 설정 파일을 수정한다
3. sshd -t 로 문법을 검사한다
4. 서비스를 재적재한다
5. 기존 세션을 닫지 말고 새 터미널에서 접속을 확인한다
6. 확인이 끝난 뒤에만 기존 세션을 닫는다

3번과 5번을 건너뛰는 사람이 정말 많다. 그리고 그중 일부가 새벽에 데이터센터로 간다.

어떻게 동작하나

검사 명령이 두 개다.

sshd -t                      # 문법만 검사sshd -T | sort | head -40    # 실제 적용될 유효 설정 전체 출력sshd -T -C user=deploy,host=10.0.3.14,addr=10.0.3.14 | grep -i 'passwordauth\|pubkey'

-t 는 문법만 본다. -T 는 최종적으로 적용되는 값을 전부 보여 준다. 이 차이가 중요한 이유는 요즘 배포판이 설정을 조각내기 때문이다.

Include /etc/ssh/sshd_config.d/*.conf

같은 키가 여러 번 나오면 sshd 는 첫 번째 값을 쓴다. 그래서 Include 가 파일 앞쪽에 있으면 조각 파일이 이기고, 뒤쪽에 있으면 본문이 이긴다. "분명히 고쳤는데 안 먹는다" 의 절반이 여기서 나온다. -T 로 확인하는 습관이 이 문제를 원천 차단한다.

권장 설정과 각 값의 의미.

PermitRootLogin noPasswordAuthentication noKbdInteractiveAuthentication noPubkeyAuthentication yesMaxAuthTries 3LoginGraceTime 30ClientAliveInterval 300ClientAliveCountMax 2AllowGroups sshusersX11Forwarding noPermitEmptyPasswords noLogLevel VERBOSE

PermitRootLogin 기본값은 prohibit-password 다. 기본 상태에서도 root 의 비밀번호 로그인은 이미 막혀 있고 키 로그인은 허용된다. 완전히 막으려면 no.
PasswordAuthentication 기본값은 yes 다. 키 인증으로 전환했다면 반드시 명시적으로 no 로 바꿔야 한다.
KbdInteractiveAuthentication 기본값도 yes 다. 비밀번호를 막았다고 생각했는데 이 경로로 들어오는 경우가 있으니 함께 끈다. 옛 이름 ChallengeResponseAuthentication 은 폐기된 별칭이다.
MaxAuthTries 기본 6. 실패가 이 값의 절반에 도달하면 그때부터 로그에 기록된다.
LoginGraceTime 기본 120초. 로그인하지 못한 연결을 오래 유지하지 않도록 줄이는 편이 좋다.
LogLevel VERBOSE 는 인증에 사용된 키의 지문을 로그에 남긴다. 감사 요건이 있으면 사실상 필수다.

Match 블록으로 예외를 만든다.

Match Group sftponly  ChrootDirectory /srv/sftp/%u  ForceCommand internal-sftp  AllowTcpForwarding no

Match 는 조건이 맞으면 다음 Match 나 파일 끝까지의 설정을 덮어쓴다. 같은 키워드가 여러 Match 에서 만족되면 첫 번째 것만 적용된다. 순서가 결과를 바꾸므로 sshd -T -C ... 로 반드시 검증한다.

현장에서 만나는 모습

접속이 안 될 때의 계층별 진단. 세 메시지의 구분이 진단의 절반이다.

Connection refused → 데몬이 안 떠 있다
Connection timed out → 경로가 막혔다
Permission denied (publickey) → 붙었고 인증에서 실패했다

그리고 ssh -vvv 를 읽는 요령. debug1: Connecting to 까지 못 가면 네트워크 문제고, Offering public key 다음에 Authentications that can continue 가 반복되면 서버가 그 키를 거부한 것이다.

다음 실습에서 할 것

drop-in 설정 파일로 sshd 를 하드닝하고, sshd -t 와 sshd -T 로 검증한다. Match 블록을 만들어 조건부 적용까지 확인하고, 마지막에 키 접속은 여전히 되고 비밀번호 인증은 거부되는지 실제로 시험한다.