대상 OS: Debian 12 (bookworm)

SFTP는 FTP보다 안전하지만, 운영에서 키가 유출되면 ‘그 키로 할 수 있는 것’이 문제다.
SFTP 전용 계정을 분리하고, sshd_config 매칭 규칙으로 권한을 줄이는 패턴을 정리한다. (작성 시각: 2026-02-25 13:08)

1) SFTP 전용 그룹/사용자 생성

sudo addgroup sftp_only
sudo useradd -m -s /usr/sbin/nologin -G sftp_only sftpuser
sudo passwd -l sftpuser

2) 업로드 디렉토리 권한 구성(chroot 대비)

sudo mkdir -p /sftp/sftpuser/upload
sudo chown root:root /sftp/sftpuser
sudo chmod 755 /sftp/sftpuser
sudo chown sftpuser:sftp_only /sftp/sftpuser/upload

3) sshd_config에서 그룹 매칭으로 SFTP만 허용

sudoedit /etc/ssh/sshd_config

Subsystem sftp internal-sftp

Match Group sftp_only
  ChrootDirectory /sftp/%u
  ForceCommand internal-sftp
  X11Forwarding no
  AllowTcpForwarding no

sudo systemctl restart ssh

사례(현장에서 자주 겪는 상황)
- 일반 운영 계정으로 SFTP를 겸용해 키 유출 시 서버 쉘까지 뚫림
- ChrootDirectory 권한 조건(root 소유 등)을 몰라 설정 후 접속이 끊김
- SFTP 계정에 포워딩이 열려 있어 내부망 pivot이 가능해짐

트러블슈팅(증상→원인→해결)
- 증상: SFTP 접속 즉시 끊김(서버 로그에 bad ownership)
원인: ChrootDirectory가 root:root가 아님
해결: /sftp/%u 디렉토리를 root 소유로 변경하고, 쓰기 폴더는 하위(upload)로 분리

- 증상: 업로드가 Permission denied
원인: upload 디렉토리 소유/권한이 잘못됨
해결: upload를 sftpuser가 쓰도록 chown/chmod 재설정

- 증상: 일반 SSH 쉘이 열림
원인: ForceCommand 누락 또는 Match 조건 미적용
해결: Match Group/Subsystem/ForceCommand를 점검하고 ssh 재시작

- 증상: 키를 분실/유출했는데 즉시 차단이 어려움
원인: authorized_keys 관리 부재
해결: 키별로 주석/관리 체계화 + 유출 시 키 교체/폐기 절차 문서화

- 증상: 내부로 터널링이 가능한 것 같음
원인: AllowTcpForwarding이 켜져 있음
해결: SFTP 전용 계정에는 AllowTcpForwarding no로 고정