대상 OS: Ubuntu Server 24.04 LTS

SSHD는 ‘외부에서 들어오는 기본 관문’인 경우가 많아서, 설정 1~2개가 보안 수준과 장애 가능성을 동시에 좌우합니다. 이 글은 운영 환경에서 sshd_config를 변경/점검할 때 반복적으로 확인하는 12개 옵션을 “왜 필요한지(위협 모델) + 어떻게 적용/검증하는지(절차)” 형태로 정리한 체크리스트입니다.

0) 변경 전 원칙(운영 안전장치)

  • 원격 접속 서버라면 현재 세션을 유지한 채 새 설정을 검증하고, 새 터미널(또는 새 SSH 세션)로 접속 테스트 후 재시작합니다.
  • 설정 문법 검증은 sshd -t로 먼저 합니다(재시작 전에 필수).
  • 배포/자동화 환경이라면 변경 내역을 파일로 백업해 롤백 가능하게 둡니다.
# 백업(최소)
sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.$(date +%F_%H%M%S).bak

# 문법 검증(필수)
sudo sshd -t

1) 운영 체크리스트: 꼭 확인하는 12개 옵션

아래 예시는 “보안 우선(키 기반) + 불필요 기능 최소화” 기준입니다. 업무 요구사항(점프호스트/포트포워딩/레거시 장비 등) 때문에 예외가 필요한 항목은 별도 승인/문서화가 권장됩니다.

(1) PermitRootLogin

권장: no

루트 직접 로그인은 크리덴셜 탈취/오탐/접속 추적 관점에서 가장 먼저 줄여야 하는 리스크입니다. 루트가 필요하면 sudo로 승격하고 감사 추적을 남기는 쪽이 일반적으로 유리합니다.

(2) PasswordAuthentication

권장: no(가능하면 키 기반 강제)

비밀번호 인증은 무차별 대입/크리덴셜 스터핑 공격의 1차 표적입니다. 키 기반 인증으로 전환하면 공격 난이도가 크게 상승합니다.

(3) PubkeyAuthentication

권장: yes

키 인증을 기본으로 쓰는 환경이라면 명시적으로 켜 둡니다(환경에 따라 기본값이 이미 yes인 경우가 많지만, 운영 표준으로 명확히).

(4) AuthenticationMethods (선택)

권장: 키만 허용 또는 키+MFA(가능한 환경)

Ubuntu 기본 OpenSSH 패키지에서 2FA는 추가 구성(예: PAM+OTP)이 필요할 수 있습니다. 최소한 “password-only”는 배제하는 방향이 안전합니다.

(5) MaxAuthTries

권장: 3~5

한 연결에서 무작위 시도를 줄여 로그/부하/계정 잠금 연쇄를 완화합니다.

(6) LoginGraceTime

권장: 20~30s

인증을 미루며 연결을 오래 잡아두는 형태(리소스 고갈/스캐너) 완화에 도움 됩니다.

(7) AllowUsers / AllowGroups

권장: 접속 가능 계정을 화이트리스트로 제한

계정이 늘어날수록 “실수로 열려 있는 계정”이 생깁니다. SSH 접근 계정은 별도 그룹(예: sshusers)로 관리하는 편이 운영에 유리합니다.

(8) PermitEmptyPasswords

권장: no

빈 비밀번호 허용은 거의 항상 사고로 이어집니다.

(9) X11Forwarding

권장: no

GUI 포워딩은 공격면/예상치 못한 의존성을 늘립니다. 서버 운영에서는 꺼두는 편이 안전합니다.

(10) AllowTcpForwarding

권장: 기본은 no, 필요 시 특정 사용자/호스트에만 제한적으로 허용

포트포워딩은 ‘SSH를 터널로 사용’하는 기능이라 내부망 우회 통로가 될 수 있습니다. 점프/운영 편의 때문에 켜는 경우가 많지만, 보안 관점에서는 통제 대상입니다.

(11) PermitTunnel

권장: no

TUN/TAP 터널 기능은 네트워크 구성을 크게 바꾸는 수준의 권한을 만들 수 있어 일반 서버에서는 꺼두는 편이 안전합니다.

(12) LogLevel

권장: VERBOSE (로그 정책/개인정보 정책에 맞춰 조정)

침해 징후 탐지/포렌식에 중요한 단서가 됩니다. 단, 너무 과한 로그는 저장/검색 비용과 개인정보 이슈를 만들 수 있으니 보관 정책과 같이 결정합니다.

2) 권장 예시 설정(요약)

# /etc/ssh/sshd_config (일부 발췌 예시)
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
PermitEmptyPasswords no

MaxAuthTries 5
LoginGraceTime 30

X11Forwarding no
AllowTcpForwarding no
PermitTunnel no

# 접속 허용 계정/그룹(예시)
AllowGroups sshusers

LogLevel VERBOSE

3) 적용 절차(안전한 변경 순서)

  1. 현재 접속 유지 + 백업 생성

    sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.bak


  2. 설정 편집(권한/감사 고려해 sudoedit 권장)

    sudoedit /etc/ssh/sshd_config


  3. 문법 검증

    sudo sshd -t


  4. 재시작 전 ‘새 세션’ 접속 테스트(가능하면)

    예: 별도 터미널에서 새로 SSH 접속 시도(키 인증/허용 사용자/그룹 등 확인)


  5. 서비스 재시작

    sudo systemctl restart ssh
sudo systemctl status ssh --no-pager


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

  • “키 로그인 준비 안 된 상태에서 PasswordAuthentication을 꺼서 원격 접속이 막힘”: 변경 전, 최소 2개 계정/키로 새 세션 접속을 검증하고 적용합니다.
  • “AllowGroups를 설정했는데 접속이 안 됨”: 사용자가 실제로 해당 그룹에 속했는지(id username) 확인하고, 그룹 반영(세션 재로그인) 여부를 점검합니다.
  • “포트포워딩을 막았더니 배포/모니터링이 깨짐”: 운영 도구가 SSH 터널에 의존하는지 확인하고, 예외가 필요하면 대상 사용자/호스트를 제한해 허용합니다.

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

  • 증상: sudo systemctl restart ssh 후 서비스가 실패
    원인: 설정 문법 오류/지원하지 않는 옵션
    해결: sudo sshd -t로 오류 라인 확인 후 수정, 저널 확인(journalctl -u ssh -n 200 --no-pager)
  • 증상: 키가 있는데도 Permission denied (publickey)
    원인: 사용자 홈/권한(authorized_keys 권한), AllowUsers/AllowGroups 제한, 키 미등록
    해결: 서버에서 sudo sshd -T | grep -E 'pubkeyauthentication|authorizedkeysfile|passwordauthentication' 확인, 권한 점검(chmod 700 ~/.ssh; chmod 600 ~/.ssh/authorized_keys)
  • 증상: 특정 사용자만 접속 불가
    원인: 그룹 제한/셸 제한/계정 잠김
    해결: id 사용자, sudo passwd -S 사용자, getent group sshusers 점검

root.so · Linux/Security 운영 노트

이 문서는 운영 환경에서의 일반적인 체크리스트이며, 조직의 정책/감사 기준/서비스 요구사항에 따라 조정이 필요합니다.